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DECODING AND DETAILED ANALYSTS OF CAPTURED 
FRAMES IN AN IEEE 802.1 1 WIRELESS LAN 



Field of Invention 

The present invention relates generally to computerized communication networks for 
permitting computers to communicate with each other in an organized manner, and more 
particularly to a network troubleshooting tool for detecting, diagnosing, and repairing 
network failures, which tool includes a method for capturing, analyzing and displaying 
detailed information about data packets or frames transmitted across a wireless 
communications network such as BEEE802.1 1 local area network (LAN). 
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Invention Background 

Over the years, the wireless communication field enjoyed tremendous growth and 
popularity. Wireless technology now reaches or is capable of reaching nearly every place on 
the face of the earth. Hundreds of millions of people exchange information every day using 
pagers, cellular phones, and other wireless communication devices. With the success of 
wireless telephony and messaging services, wireless technology has also made significant 
inroads into the area of personal and business computing. Without the constraints imposed by 
wired networks, network users can move about almost without restriction and access a 
communication network from nearly any location, enabling wireless transmission of a variety 
of information types including data, video, voice and the like through the network. 

Many different forms data communication protocols have been developed for 
enabling computers to communicate with one another in an orderly manner. For example, 
several proprietary versions of wireless local area networks (LANs) were implemented for 
testing and development. One wireless network standard that was recently adopted by the 
wireless community is the BEEE802. 1 1 LAN, which led to a surge in use of wireless LANs, 
The IEEE802.1 1 standard establishes specifications on the parameters of both the medium 
access control and the physical layers for enabling wireless connectivity between fixed, 
portable, and moving stations within a local area. The term "station" refers hereinafter to an 
active or passive device part of a computer network that is capable of communicating at least 
one data packet or frame within the computer network. Such stations include, but not limited 
to, personal computers, servers, routers, printers, personal digital assistants, scanners and data 
collectors, palmtop computers, handheld PCs, pen-based computers, and the like. 

According to the IEEE802.il standard, the physical layer that handles transmission of 
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data between stations, may utilize either direct sequence spread spectrum, frequency hopping 
spread spectrum or infrared (IR) pulse position modulation. The medium access control layer 
(MAC) comprises a set of protocols that is responsible for maintaining order in the use of the 
shared medium. In accordance with the MAC protocol, when a station has a data packet or 
frame to be transmitted, it first listens to ensure no other station is transmitting. If the channel 
is clear, it then transmits the packet. Otherwise, it chooses a random "backoff factor" that 
determines the amount of time the station must wait until it is allowed to transmit the packet. 
During periods in which the channel is clear, the transmitting station decrements its backoff 
counter, and when the channel is busy it does not decrement its backoff counter. When the 
backoff counter reaches zero, then the station transmits the packet. Since the probability that 
two stations will choose the same backoff factor is small, collisions between packets are thus 
minimized. In certain environments, befdte a packet is to be transmitted, the transmitting 
station initially sends a short request-to-send (RTS) packet containing information on the 
length of the time required to transmit the packet. If the receiving station hears the RTS, it 
responds with a short clear-to-send (CTS) packet. After this exchange, the transmitting station 
sends its packet. When the packet is successfully received, as determined by a cyclic 
redundancy check (CRC), the receiving station transmits an acknowledgement (ACK) packet 

Like wired network counterparts, wireless networks may, during operation, encounter 
network difficulties or anomalies including, but not limited to, data traffic congestion at peak 
usage, point failures, and the like. Such network difficulties negatively impact network 
responsiveness and throughput. As a result, network users experience productivity loss, 
network processing delays and other disruptions. A measure of a network's performance is 
often referred to as the quality of service. Quality of service is typically measured by 
responsiveness, including the amount of time expended waiting for images, text, and other 
data to be transferred, and by throughput of data across a communications channel. Other 
aspects may be application-specific, for example, quality of playback, jitter, quality of the 
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data transmitted over the communication channel, and the like. In order to troubleshoot, 
maintain, and optimize the performance of communication networks, the data traffic flowing 
through the communication channel is monitored, tested and analyzed to provide rapid 
detection, diagnosis and correction of network failure and system breakdown, through use of 
tolls developed for this purpose. Network Associates, Inc., of Santa Clara, California, has 
been in the forefront of technology for many years in developing and providing software for 
managing and troubleshooting computer networks. The software is known as "Sniffer® 
Software". 

In the course of testing and analyzing a network's quality of service, a network 
monitoring tool is typically used to access a passive station positioned at a point along a 
wired network connection or communication channel through which all of the data traffic of 
interest streams. By accessing the passive station with the network monitoring tool, all the 
data traffic passing through the corresponding network connection may be easily tracked and 
observed. Any irregularities in the data traffic flow may then be readily detected and analyzed 
to determine the source of a particular anomaly. This type of analysis is referred to as 
promiscuous mode analysis. Such wired network analysis techniques, however, would fail to 
monitor data traffic transmitted over wireless communication channels. In network systems 
where wireless and wired networks are connected, the monitoring tool accessing the passive 
station of the wired network portion would fail to perceive any of the data traffic transmitted 
along the wireless portion of the network. 

For the foregoing reasons, there is a need to provide network analysis tools with a 
method for both extracting data packets or frames transmitted in a network such as between 
wireless stations, or between wireless stations and access points in a wireless LAN, and 
displaying the detail information contained in the data packets or frames for the user. The 
limitation of the processing power and available memory of the computers may make the real 
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time detailed analysis of the frames virtually impossible. Therefore, the data packets or 
frames are captured in a buffer while the monitoring tool performs a real time analysis. The 
captured data packets or frames are later replayed for further detailed analysis and display. 

Summary nfTnvAnti^n 

The present invention is generally directed to a method for displaying and analyzing 
information contained in data packets or frames transmitted along a wireless communication 
channel. The method of the present invention provides the benefits of efficient network 
monitoring using a detailed offline analysis of the frames after they are captured in a buffer, 
thus greatly assisting the maintenance and troubleshooting of the network. 

In particular, one aspect of the present invention is directed to a method of decoding 
information contained in an IEEE802. 1 1 1 header of data packets or frames transmitted 
between stations in a wireless local area network, the method comprising steps of: 

(a) establishing a direct wireless logical connection with the wireless communications 
network; 

(b) receiving wirelessly, in real-time, data packets or frames transmitted in the wireless 
communication network; 

(c) storing in a memory storage device, the data packets or frames captured; and 

(d) decoding and displaying the information contained in the IEEE802.1 1 header of the 
data packets or frames stored in the capture buffer. 

In another aspect of the present invention, there is provided a network monitoring apparatus 
for capturing and selectively filtering data frames transmitted between stations in a wireless 
communications network. The apparatus of the present invention comprises: 

a wireless network interface device working in a promiscuous mode within a wireless 
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communications network, for capturing a plurality of frames transmitted through the network; 

a user interface system comprising input and output devices for enabling a user to input and 
obtain information associated with plurality of captured frames; 

a memory storage device for storing the plurality of captured frames from the wireless 
communications network; and 

a processor device electronically connected to a network interface device, the user interface 
system, and memory storage device, the processor device being programmed to execute a 
routine comprising the steps of: 

■* 

(a) establishing a direct wireless logical connection with the wireless communications 
network via the network interface device; 

(b) receiving wirelessly, in real-time, frames transmitted in the wireless communications 
network via direct wireless logical connection; 

(c) receiving one or more frame attribute parameters inputted by a user through the user 
interface system; 

(d) storing in the memory storage device, the frames received from the wireless network 
via direct wireless logical connection; 

(e) decoding in detail and displaying to the user, the information contained in the frames 
stored in the memory storage device. 

Brief Description of the Drawings 

Various embodiments of the present invention are described in detail with reference to 
the drawings, in which like items are identified by the same reference designation, wherein: 
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Figure 1 shows a block schematic diagram of a computer network comprising a 
wireline network in communication with an EEEE802.1 1 wireless media Local Area Network 
(LAN); 

Figure 2 A shows a layout of the general frame format of a MAC frame for the 
IEEE802.il standard; 

Figure 2B shows a detailed layout of the frame format of a Frame Control Field of the 
MAC frame shown in Figure 2A; 

Figure 2C shows a layout of a WEP encrypted frame format. 

Figure 3 shows a flowchart of a frame decoding routine for one embodiment of the 
present invention; 

Figure 4 shows a flowchart of a routine for determining the parameters used by the 
decoding routine of the present invention; 

Figure 5 shows a flowchart of a routine that determines the parameters necessary for 
assembling the fragmented frames associated with the decoding routine of the present 
invention; 

Figure 6 is a flowchart of a routine for determining the source and destination address 
of the frame associated with the decoding routine of the present invention; 

Figure 7 shows a flowchart of a routine for determining the summary line display of 
frames associated with the decoding routine of the present invention; 
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Figure 8 shows the flowchart of a routine for formatting and displaying in detail the 
contents of frames associated with the decoding routine of the present invention; 

Figure 9 shows the flowchart of a routine for formatting and displaying in detail the 
contents of management frames associated with the decoding routine of the present invention; 

Figure 10 shows the flowchart of a routine for formatting and displaying in detail the 
contents of management subtype frames associated with the decoding routine of the present 
invention; 

Figure 1 1 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Association Request frames associated with the decoding routine of the present • 
invention; 

Figure 12 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Reassociation Request frames associated with the decoding routine of the present 
invention; 

Figure 13 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Association Response and Reassociation Response frames associated with the 
decoding routine of the present invention; 

Figure 14 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Probe Request frames associated with the decoding routine of the present 
invention; 
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Figure 15 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Probe Response frames associated with the decoding routine of the present 
invention; 

Figure 16 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Beacon frames associated with the decoding routine of the present invention; 

Figure 17 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Disassociation frames associated with the decoding routine of the present 
invention; 

Figure 18 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Authentication frames associated with the decoding routine of the present 
invention; 

Figure 19 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Deauthentication frames associated with the decoding routine of the present 
invention; 

Figure 20 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Control frames associated with the decoding routine of the present invention; 

Figure 21 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Power Save Poll frames associated with the decoding routine of the present 
invention; 
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Figure 22 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Request To Send frames associated with the decoding routine of the present 
invention; 

Figure 23 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Acknowledgement and Clear To Send frames associated with the decoding 
routine of the present invention; 

Figure 24 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Contention Free End (CF-End) and Contention Free End Acknowledgement (CF- 
End+Ack) frames associated with the decoding routine of the present invention; 

Figure 25 shows the flowchart of a routine for formatting and displaying in detail the 
contents of Data frames associated with the decoding routine of the present invention; 

Figure 26 shows the flowchart of a routine for determining the parameters necessary 
for upper layers decoding routines; 

Figure 27 shows the flowchart of a routine for formatting and displaying in detail the 
physical layer information of the frames associated with the decoding routine of the present 
invention; 

Figure 28 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Frame Control Field associated with the decoding routine of the present 
invention; 
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Figure 29 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Destination Address Field associated with the decoding routine of the present 
invention; 

Figure 30 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Source Address Field associated with the decoding routine of the present 
invention; 

Figure 31 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a BSSDD Field associated with the decoding routine of the present invention; 

Figure 32 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Receiver Address Field associated with the decoding routine of the present 
invention; 

Figure 33 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Transmitter Address Field associated with the decoding routine of the present 
invention; 

Figure 34 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Sequence Control Field associated with the decoding routine of the present 
invention; 

Figure 35 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Capability Information Element associated with the decoding routine of the 
present invention; 
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Figure 36 shows the flowchart of a routine for formatting and displaying in detail the 
contents of an SSBD Information Element associated with the decoding routine of the present 
invention; 

Figure 37 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Supported Rates Information Element associated with the decoding routine of 
the present invention; 

Figure 38 shows the flowchart of a routine for formatting and displaying in detail the 
contents of an Unknown Information Element associated with the decoding routine of the 
present invention; 

Figure 39 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a DS Parameter Set Information Element associated with the decoding routine of 
the present invention; 

Figure 40 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a CF Parameter Set Information Element associated with the decoding routine of 
the present invention; 

Figure 41 shows the flowchart of a routine for formatting and displaying in detail the 
contents of an IBSS Parameter Set Information Element associated with the decoding routine 
of thepresent invention; 

Figure 42 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a TIM Parameter Set Information Element associated with the decoding routine of 
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the present invention; 

Figure 43 shows the flowchart of a routine for formatting and displaying in detail the 
contents of a Challenge Text Information Element associated with the decoding routine of the 
present invention; 

Figure 44A shows the layout for an Authentication Algorithm Number Fixed Field 
associated with the decoding routine of the present invention; 

Figure 44B shows the layout of a Authentication Transaction Sequence Number Fixed 
Field associated with the decoding routine of the present invention; 

Figure 44C shows the layout of a Beacon Interval Fixed Field associated with the 
decoding routine of the present invention; 

Figure 44D shows the layout of a Listen Interval Fixed Field associated with the 
decoding routine of the present invention; 

Figure 45 A shows the layout of a Reason Code Fixed Field associated with the 
decoding routine of the present invention; 

Figure 45B shows the layout of an Association ID Fixed Field associated with the 
decoding routine of the present invention; 

Figure 45 C shows a layout of a Status Code Fixed Field associated with the decoding 
routine of the present invention; 
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Figure 45D shows a layout of a Current Access Point Address Fixed Field associated 
with the decoding routine of the present invention; 

Figure 46A shows a layout of a Timestamp Fixed Field associated with the decoding 
routine of the present invention; 

Figure 46B shows a layout of a Capability Information Fixed Field associated with the 
decoding routine of the present invention; 

Figure 46C shows a layout of an SSID Information Element Format associated with 
the decoding routine of the present invention; 

Figure 47A shows a layout of a Supported Rates Information Element Format 
associated with the decoding routine of the present invention; 

Figure 47B shows a layout of a DS Parameter Set Information Element Format 
associated with the decoding routine of the present invention; 

Figure 47C shows, a layout of a CF Parameter Set Information Element Format 
associated with the decoding routine of the present invention; 

Figure 48 A shows a layout of a TIM Information Element Format associated with the 
decoding routine of the present invention; 

Figure 48B shows a layout of an IBSS Information Element Format associated with 
the decoding routine of the present invention; 
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Figure 48C shows a layout of a Challenge Text Information Element Format 
associated with the decoding routine of the present invention; 

Figure 4SD shows a layout of an Unknown Information Element Format associated 
with the decoding routine of the present invention; 

Figures 49 through 73, respectively, show screen displays for use in one embodiment 
of the invention. 

Detailed Description of the Invention 

The present invention is generally directed to a method and apparatus for capturing 
data packets and frames transmitted through a corresponding wireless communication 
channel and decoding and displaying to the user, the information contained in such frames. 
The present invention significantly improves one's understanding of the type of data traffic 
on the wireless network by way of a detailed analysis and decoding of the contents of the 
wireless header in the frames. A recently introduced Sniffer® Wireless" product of Network 
Associates, Inc., of Santa Clara, California, incorporates various embodiments of the present 
invention. 

The present invention is used in network analysis tools for wireless Local Area 
Network (LAN) systems conforming to the DBEE802. 1 1 standard, but is not meant to be so 
limited. A wireless LAN system includes a plurality of devices or stations, such as 
workstations, printers, storage devices, servers, and the like connected to one another by 
wireless communications channels. The wireless LAN is configured so as to enable a 
message, usually a data packet or frame to be directed from a source to a destination. In this 
regard, each station of interest is provided with a network address that is unique to that 
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particular station in the computer network. Typically, each station will have a single network 
address that is used by the system in order to locate that particular station. In this manner, 
any information or data that is to be transmitted or relayed to a specific station is 
accomplished by the use of the network addressing system. Although an IEBE802.il -based 
wireless LAN system is described in connection with the present invention, one of ordinary 
skill in the art will understand that the present invention may be applied in other types of 
communication networks. 

With reference to Figure 1, one configuration of a wireline and wireless LAN-based 
communication network 10 is shown. The network 10 comprises a plurality of wireless 
stations 12, and a wireless local bridge or access point 14 connected to a wireline network 16 
of a plurality of wired stations 18. Each 6f the wireless stations 12 include a wireless network 
interface device 1 1 for interfacing with other wireless stations 12 and with the access point 14 
to form a wireless network 13. Such a wireless network interface device, for example, is a 
Cisco Aironet Series 340 or Series 350 Wireless LAN Adapter, Cisco Systems, San Jose, 
California, or is a Symbol Technologies Spectrum 24 High Rate Adapter LA-4121-1020US. 
The wireless network interface device 1 1 transmits digital signals from the wireless stations 
12 to the wireless medium to enable efficient signal transfer between a sending station and a 
receiving station, typically in the form of RF signals. The access point 14 enables 
communication between the wireless network stations 12 and the wired network stations 1 8, 
thereby expanding the associated LAN's capability. Note that although only one access point 
14 is shown, in certain applications, a plurality of acccess points may be used. Information, 
control signals and other forms of digital data can be transmitted between stations 12 and 18 
in the form of discrete data frames via network 10. The data frames, as one skilled in the art 
will recognize, are provided in a specific format commonly used in the transmission of data 
through the network 10. 
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A wireless network monitoring tool 80 of the present invention, as shown for example 
in Figure 1, includes a wireless network interface device 1 1 connected to a wireless LAN 
network interface card (NIC) 81 for creating a connection with the LAN 10 so as to determine 
the topology of the LAN 10 and to monitor other network functions and data frame 
transmissions. The monitoring tool 80 further includes a processing unit or CPU 82 to receive 
information regarding the operation of the network 10. A memory 83 and a storage device 84 
are connected to the processor 82 to provide temporary and permanent storage, respectively, 
of information required by the processor 82. A display unit 85 is connected to the processor 
82 so as to display, generally in graphical form, information about the network 10 including 
its topology, data traffic stream, and functions and services. Through input devices 86 such 
as a keyboard, a mouse and the like, connected to the processor 82, and through a graphical 
user interface, a user can perform various analysis of the network 10 and monitor data 
transmissions. The display unit 85, the input devices 86, and the graphical user interface are 
collectively referred to as a user interface system. The monitoring tool 80 can be considered 
just another station in the wireless network, similar to the workstations, printers, storage 
devices, servers, and so forth, but it runs in a promiscuous mode, which will enable it to 
receive and analyze the packets sent to other stations as well. 

The graphical user interface is preferably executed on a processor capable of 
supporting at least one of Windows NT 4.0, Windows 98SE, or Windows 2000 Professional. 
Any one of a number of commercial or proprietary processors may be used. Generally, the 
processor 82 of a Sniffer^ Wireless, for example, requires a mrnnrmtn of 128 MB 
(Megabytes) of RAM, 256 MB (Megabytes) of Swap Space, and 4 MB (Megabytes) of 
available disk drive space. However, these requirements are meant to be limiting, and can 
vary with the type of processor used. The present invention can be built using available 
components or modules. 
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For the purposes of this invention, a frame represents a discrete logical unit of data 
transmitted through a communications network or channel from a sender station to a 
receiving station. The data is commonly a fragment of a much larger set of data, such as a file 
of text or image information. As the larger file is prepared for transmission, it is fragmented 
into smaller data units. Each fragment of data is packaged into a frame format, which 
comprises a header, payload, and trailer. The header prepends the payload and includes a set 
of framing bits, which are used for purposes of frame delineation and synchronization of the 
receiving station with the speed of transmission across the transmission link. Also included in 
the header are routing control information, and address information. Following the header is 
the payload, which contains the data unit being transmitted. Appending the payload is the 
trailer, which comprises data bits used for error detection and correction, and a final set of 
framing bits, or ending flag for purposes *of frame delineation. The frame format of a frame is 
specific to the data communications protocol (i.e., IPX, IP, LLC, SNAP, etc.) being utilized 
in the network. The present invention is described in correspondence with the frame format 
used in IEEE802.1 1 LANs, although it will be understood that the present invention may also 
be modified for use in connection with other types of frame formats and data communications 
protocols. 

The IEEE802.1 1 wireless LAN system includes a MAC (Medium Access Control) 
layer embodying a set of protocols which are responsible for maintaining order in the use of a 
shared medium. There are three types of frames that are transmitted at the MAC layer. The 
following list summarizes the frame types and subtypes and their main function or service in 
connection with the 802. 1 1 MAC layer protocols: 

IV,. IEEE802.il Man agement Frames : The purpose of 802.1 1 management frames is to 
establish and maintain communications between stations and access points. Thus, 
management frames provide such services as association and authentication. 



18 



WO 03/025597 



PCT7US02/29303 



a) Association Request frame: A station will send this frame to an access point if it 
wants to associate with that access point If the access point grants permission for 
association, the station will be associated with the access point. 

b) Association Response frame: After receiving an Association Request frame, an access 
point sends an Association Response frame to indicate the result of an association 
request. 

c) Reassociation Request frame: A station will send this frame to an access point if it 
wants to reassociate with that access point. 

d) Reassociation Response frame: The access point sends the Reassociation Response 
frame to indicate the result of a reassociation request. 

e) Probe Request frame: A station sends a probe response frame to obtain information 
from another station or access poilit. 

f) Probe Response frame: If a station or access point receives a Probe Request frame, it 
will respond to the sending station with a Probe Request frame containing specific 
parameters about itself. 

g) Beacon frame: In an infrastructure network, an access point periodically sends a 
Beacon frame that contains a timestamp and configuration information about the 
access point. 

h) ATTM frame: A station which has frames buffered for other stations sends an ATIM 
(Announcement Traffic Indication Message) frame to each of these stations during an 
ATTM window immediately following, the transmission of a Beacon frame. 

i) Disassociation frame: If a station or an access point wants to disassociate, it will send 
this frame. 

j) Authentication frame: A station sends an Authentication frame to a station or an 

access point for which it requests secure communication, 
k) Deauthentication frame: A station sends a Deauthentication frame to a station or 

access point for which it requests to end a secure communication. 
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2} IEEE802.1 1 Control Frames : After establishing association and authentication between 
stations and access points, control frames provide the functionality to assist in the delivery 
of data frames. 

a) Request to Send (RTS): A station sends an RTS frame to a receiving station to 
negotiate the sending of a data frame that will follow. 

b) Clear to Send (CTS): The station that is the receiver of the RTS frame sends a CTS 
frame to acknowledge the right for the sending station to send the data frames. 

c) Acknowledgment (ACK): When a station receives an error-free frame, the station can 
send an ACK frame to the sending station to acknowledge that it successfully received 
the frame. 

d) Power-Save Poll (PS Poll): If a station receives a PS Poll frame, it updates its network 
allocation vector (NAV), which is* an indication of time periods that a station will not 
initiate a transmission. 

e) Contention-Free End (CF End): The CF End frame designates the end of a contention 
free period. 

f) CF End + CF-ACK: This frame acknowledges the Contention-Free End 
announcement of a CF End frame. 

3} IEEB802.1 1 Data Frames : The main purpose of data frames is to cany information to the 
destination station for handoff to its applicable LLC (Logical Link Control) layer. 

With reference to Figure 2A, the frame format of a MAC frame 20 is shown. The 
frame 20 comprises generally a MAC header 22, a payload or frame body 24, and a trailer or 
frame check sequence 26. The MAC header 22 may further include at least one of the 
following information fields: a frame control field 28 for carrying control information being 
sent from station to station, a duration/ID field 30 for carrying information about the time 
duration the channel will be reserved or the association id, Address 1-4 fields 32, 34, 36, and 
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38, respectively, which convey the Basic Service Set Identification (BSSID), source address, 
destination address, sending station address, and receiving station address, respectively, and a 
sequence control field 40 which indicates the sequence and fragment numbers of the frame 
20. The frame body 24 includes a variable length payload and carries information that 
pertains to the specific frame being sent. The data frame may contain a data unit The 
control frames don't have a frame body 24. The MAC management frames may include 
specific parameters in the frame body 24 that pertain to a particular service or network 
functions the frame is implementing. The frame check sequence 26 contains information that 
is used to validate successful reception of frame 20. The frame format of the MAC frame 20, 
shown in Figures 2A and 2B, is true for all frames transmitted by a sending station to a 
receiving station, regardless of frame type. However, some of the fields may be omitted from 
control and management frames as explained in the IEEE802.1 1 standard. 

As shown in Figure 2B, the frame control field 28 which carries the critical control 
information may be further broken down into a protocol version subfield 42, a frame-type 
subfield 44, a frame-subtype subfield 46, a "To DS' C and "From DS" subfields 48 and 50, 
respectively, a "More Frag" subfield 52, a Retry subfield 54, a Power Management subfield 
56, a "More Data" subfield 58, a "WEP (wired equivalent privacy)" subfield 60, and an 
"Order*' subfield 62. The protocol version subfield 42 indicates the version number of the 
data communication protocol creating the frame 20. The Type subfield 44 contains 
information that defines whether the frame 20 is a management, control, or data frame as 
indicated by the bits in Table 1 below. The Subtype subfield 46 contains information that 
defines the service or function of the frame 20 also shown in Table 1 below. 
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Type 


Type 


Subtype 


Subtype description 


value 


description 


value 


b3 b2 




b7 b6 b5 b4 




00 


Management 


uuuu 


Association renuest 


00 


Management 


0001 


Association resnnnsfi 


00 


Management 


0010 


Reassociation reanest 


00 


Management 


0011 


Reassociation resnonse 


00 


Management 


0100 


Probe request 


00 


Management 


0101 


Probe response 


00 


Management 


0110-0111 


Reserved 


00 


Management 


1000 


Beacon 


00 


Management 


1001 


Announcement traffic indication tne^wap 
(ATHvl) 


00 


Management 


1010 


Disassociation 


00 


Management 


1011 


Authentication 


00 


Management 


1100 


Deaiithenticati on 


00 


Management 


1101 - 1111 


Reserved 


01 


Control 


0000 - 1001 


Reserved 


01 


Control 


1010, 


Power Save (PS)-Poll 


01 


Control 


1011 


Reauest To Send rRTS^ 


01 


Control 


1100 


Clear To Send fCTS} 


01 


Control 


1101 


Acknowledgement (ACK) 


01 


Control 


1110 


Contention-Free (CF)-End 


01 


Control 


1111 


CF-End + CF-Ack 


10 


Data 


0000 


Data 


10 


Data 


0001 


Data + CF-Ack 


10 


Data 


0010 


Data + CF-Poll 


10 


Data 


0011 


Data + CF-Ack + CF-Poll 


10 


Data 


0100 


Null function (no data) 


10 


Data 


0101 


CF-Ack (no data) 


10 


Data 


0110 1 


CF-Poll (no data) 


10 


Data 


0111 


Cf-Ack + CF-Poll (no data) 


10 


Data 


1000-1111 


Reserved 


11 


Reserved 


0000-1111 


Reserved 



Table 1. Valid type and subtype combinations 



The "To DS" subfield 48 and the "From DS" subfield 50 defines whether the frame is 
destined to a distribution system or leaving a distribution system, respectively. The term 
"distribution system" refers to a system used to interconnect a set of basic service sets (BSS) 
and integrated LANs to create an extended service set (ESS). The *To D3" subfield 48 and 
the "From DS" subfield 50 are set to zero for all management and control frames, because 
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these frame are valid only within a basic service set (BSS). Depending on the bit sequence set 
in the "To DS" and "From DS" subfields 48 and 50 of a data frame, the contents of the 
Address 1-4 fields 32, 34, 36, and 38 will have a specific meaning. Table 2 lists the possible 
values of the address field depending on the bit sequence set for the "To DS (Distribution 
System)" and "From DS" subfields, as shown below. 



ToDS 


From DS 


Address 1 


Address 2 


Address 3 


Address 4 


0 


0 


DA 


SA 


BSSID 


N/A 


0 


1 


DA 


BSSID 


SA 


N/A 


1 


0 


BSSED 


SA 


DA 


N/A 


1 


1 


RA 


TA 


DA 


SA 



Table 2. Address field contents for data frames 



A station uses the contents of the "Address 1" field 32 to perfonn the address matching 
of target receiving stations. In cases where the "Address 1" field 32 contains a broadcast 
address (OxFFFFFFFFFFFF) or group address (multicast address), the BSSID is also validated 
to ensure that the broadcast or multicast originated in the same BSS (basic service set). 

The receiving station uses the contents of the "Address 2" field 34 of the current frame 
to direct the acknowledgement (if acknowledgement is necessary). The DA (destination 
address) is the destination of the data residing in the "Frame Body" field 24 of frame 20. The 
SA (source address) is the address of the MAC entity that initiated the data that is carried in 
the "Frame Body" field 24. The RA (receiver address) is the address of the station contained in 
the access point in the wireless distribution system that is the next intended recipient of the 
frame. The TA (transmitter address) is the address of the station contained in the Access Point 
in the wireless distribution system that is transmitting the 
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frame. The "BSSID (Basic Service Set Identification)'* field contains either the MAC address 
of the Access Point or the BSSID of the IBSS( Independent Basic Service Set). If the content 
of the "Address 4" field 38 is shown as "N/A (not applicable)" then this address field is 
omitted from the frame. 

The "More Frag" subfield 52 indicates whether another fragment of the same frame 20 
will follow in a subsequent frame. EEEE802.il protocol allows management and data frame 
types to be fragmented at the MAC layer in order to increase the possibility of delivery of the 
original large frame. The receiving station supports mechanism that will allow it to reassemble 
the fragmented frames originated from a sending station. The "Retry" subfield 54 indicates 
whether the frame 20 is a retransmission of an earlier frame where the reason for 
retransmission may be due to errors in the transmission of the first frame that resulted in an 
unsuccessful frame check sequence processing. 

The Power Management subfield 56 indicates the power management mode that the 
sending station will reside after the current frame exchange sequence. The "More Data" 
subfield 58 alerts the receiving station in power-save mode to prepare to receive additional 
frames. The "Wired Equivalent Privacy* (WEP) subfield 60 indicates to the receiving station 
that the data contained in the frame body 24 has been processed by a wired equivalent privacy 
algorithm, that is, the data bits have been encrypted using a secret key for increased security 
and privacy. The order subfield 62 indicates whether the frame 20 was sent using the "Strictly 
Ordered" service class, which tells the receiving station that frames must be processed in a 
particular order and indicating the order sequence. The bit data contained in the corresponding 
fields and subfields of the frame 20, provides information as to the frame type and subtype as 
well as its service or function of the corresponding frame. 
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The Network Monitoring tool 80 (as shown in Figure 1) operates to wirelessly "tap" 
into the wireless network 13 and capture the data frames transmitted in the network. In one 
embodiment of the present invention, the user, upon capturing the transmitted frames, may 
choose to decode and analyze the information contained in the captured frames. Even though 
the general structure of the IEEE802. 1 1 frames fit the frame format of a MAC frame 20 shown 
in Figure 2 A, actual frame format depends on the frame type of the frame. Therefore the 
decoding and detailed analysis for each frame type are processed separately. 

With reference to the flowcharts of Figure 3 through 43, the operation of the present 
invention will be described in greater detail. With reference to Figure 3, the routine of the 
present invention is initiated in step 300 of the friterpret_802_110 routine. In step 300 the user 
initiates the decoding process, typically by use of a menu on a display screen. For example, in 
Figure 49, a display provided in the "Sniffer® Wireless" product of Network Associates, Inc. is 
shown. A user uses their mouse to open the 'Tile" menu item. The user then selects the 
"Open" sub menu item by way of a mouse cursor. This process opens a dialog window as 
depicted in Figure 50. The user selects the captured file to be loaded into the system memory 
84. As the network monitoring tool 80 loads the captured file, the information contained in 
each frame is analyzed in detail by calling Inteipret_802_l 10 routine at step 300 for each 
frame in the capture buffer 83 in the order they are stored into the buffer 83. 

With respect to the flowchart of Figure 3, the Interpret_802_l 10 programming routine 
is defined in steps 300 through 307. The Interpret_802_l 10 routine decodes the information 
contained in each bit of the IEEE802. 1 1 header of the frames captured wirelessly form the 
network 10. The routine first determines the parameters which are necessary to decode the 
BBEE802. 1 1 header further by executing a routine referred as 

Detennine_802_l l_DecodingParametersO at step 301 as described in greater detail by the 
flowchart of Figure 4. In step 302 of Figure 3, the routine next determine if the current frame 
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is a part of a bigger fragmented frame, and if it needs to be reassembled by executing a routine 
called PreScan_802_l 1Q. The detail of the PreScanJ502j[ 10 routine is described in greater 
detail by the flowchart of Figure 5. At step 303 of Figure 3, the Interpret_802_l 10 routine 
then proceeds to determine and display the source and destination addresses of the frame by 
calling a routine called Scan_802_l 10 at step 303 as described in greater detail by the 
flowchart of Figure 6. The Interpret_802_l 10 routine executes the 

Format _802_1 l_Summary0 routine at step 304 to display the summary information about the 
contents of the frame as described in greater detail by the flowchart of Figure 7, Then the 
routine proceeds to call the Foimat_802_l l_DetaiI0 routine at step 305 to perform a detailed 
analysis of the information contained in the EEEE802. 1 1 header of the frame as described in 
greater detail by the flowchart of Figure 8. The decoding of the information contained in the 
frame is done in a different routine for each layer. In order to determine the parameters 
required for further decoding of the contents of the frame by higher layer protocol interpreters, 
the Interpret_802_l 10 routine calls the PrepareForUpperLayerDecodingO routine at step 306 
as described in greater detail by the flowchart of Figure 26. The Interpret_802_l 10 300 is 
terminated at step 307. 

As shown in Figure 4, the software initiates a routine called 
Determine_802_ll_DecodingParameters0 denoted at step 301. The routine referred generally 
at step 301 in Figure 3, functions to determine the parameters required to decode the 
information in each frame. After initiating the routine 301, the programming or routine 
proceeds to execute GetFrameTypeO and GetFrameSubtypeO functions at step 401 to 
determine the frame type and subtype of the current frame. The GetFrameTypeO and 
GetFrameSubtypeO functions return the frame type and subtype by checking the 'Type" and 
"Subtype" fields 44 and 46, respectively. The routine determines the frame type and subtype 
according to the corresponding bit values listed in Table 1. The results of the GetFrameTypeO 
and GetFrameSubtypeO functions are stored in the "ulFrameType" and <6 ulFrameSubtype" 
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variables. The routine proceeds to step 402 to determine if the frame type is a 'Management" 
frame. If "Yes", then the routine proceeds to step 406 where the value of the variable 
"ulHeaderLength" is set to 24, which is the length (in octets) of the IEEE802. 1 1 header for the 
management frames. If the result of step 402 is "No" then the routine proceeds to step 403 to 
determine if the frame type is a "Control" frame. If "Yes", then the routine proceeds to step 
407 to determine if the frame subtype is either an "Acknowledgement (ACK)" or "Clear to 
Send (CTS)" frame. If "Yes", then the routine proceeds to step 408 to set the value of the 
variable "ulHeaderLength" is set to 10, which is the IEEE802.1 1 header length for ACK and 
CTS frames. If the result of step 407 is "No", which means the frame subtype of the Control 
frame is other than an ACK or CTS frame, the routine proceeds to step 409 to set the value of 
the variable "ulHeaderLength" to 16. If the frame type is not a Control frame at step 403, then 
the routine proceeds to step 404 to determine if the frame type is a "Data" frame. If "Yes", the 
routine proceeds to step 410 to determine if both of the ToDS and FromDS fields 48 and 50 
are set to one. If "Yes", then the value of the variable "ulHeaderLength" is set to 30 at step 
41 1, and if <€ No" it is set to 24. If the frame type is not a data frame at step 404, the routine 
proceeds to set the value of the variable "ulHeaderLength" to zero. The 
Determine_802__ll_DecodingParemetersO routine of step 400 is terminated at step 413. 

With reference to Figure 5, the program executes the PreScan_802_ll() routine (step 
302 of Figure 3) as denoted by steps 501 to 515. The role of this routine is to determine the 
parameters needed to reassemble the fragmented frames. The program initiates the 
PreScan_802_l 10 routine at step 302. The routine proceeds to step 501 to determine if the 
frame type is a "Control" frame or a frame with an error or it is an encrypted frame. If "Yes", 
then the routine proceeds to step 502 to disable the reassembly for the current frame. The 
Control frames are not fragmented in the IEEE802. 1 1 standard. The frames with an error are 
not used in assembly because the contents of the frames may be wrong. The encrypted frames 
will not be decoded at the higher layer, because the higher layer decoding functions will not 
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understand the contents of the frame. If the result of step 501 is tc No", then the routine 
proceeds to step 503 to determine if the current frame is originally encrypted but decrypted by 
the network analysis tool 80 upon receiving the frame. Since the decryption is done in place, 
the decrypted frame will have a 4-octet "IV" field 66 that contains the initialization vector for 
the encryption. At the end of the frame body field 76, there will be an "ICV" (Integrity Check 
Value) field 70, which is 4 octets in length. If the result of step 503 is "Yes", the routine 
proceeds to step 504 where the frame length is reduced by 4 octets due to "ICV" field 70, and 
the data offset that the upper layers start decoding will be increased from the protocol header 
length by 4 octets due to the length of the "TV" field 66. However, if the frame is not originally 
encrypted and later decrypted (step 503), then the data offset will be set to the length of the 
MAC header, and the fragment length will be set to the length of the frame at step 505. The 
routine then proceeds to step 506 to determine if "More Frag" field 52 is set to one (There will 
be more fragments belonging to the original large frame). If <c Yes'\ then it proceeds to step 
507 to determine if the fragment number of the current frame is zero. If "Yes", then the routine 
proceeds to step 509 where the fragment type is set to "First Fragment", the data offset is set to 
zero, and the reassembly is enabled. If the fragment number is not zero (step 507), then the 
routine proceeds to step 508, where the fragment type is set to "Middle Fragment", the 
fragment length is reduced by the data offset (which corresponds to IEEE802.il header field 
64 length plus the length of the 6 TV" field 66), and the reassembly is enabled. If the "More 
Frag" field 52 is not set to one, then the routine proceeds to step 5 10 to determine if the 
fragment number is zero. If "Yes", then it proceeds to step 511 where it disables the 
reassembly of the current frame because it is single fragment. However, if the fragment 
number is not equal to zero (step 510), then it proceeds to step 512, where it sets the fragment 
type to <c Last Fragment", reduces the fragment length by data offset, and enables the 
reassembly. The routine then proceeds to step 513 to determine if the frame is a decrypted 
frame. If <c Yes", it proceeds to step 514 to increase the fragment length by 4 octets due to the 
length of the "ICV" field 70. If "No" at Step 513, the routine proceeds to Step 515. The 
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PreScan_802_l 10 routine ends at step 515. 

As shown in Figure 6, the program executes the Scan_802_l 10 subroutine 303 
generally shown in Figure 3. The Scan_802_l 10 routine is responsible for detemiining and 
displaying the source and destination addresses of the frame. After initiation at Step 303, the 
routine than proceeds to step 601 to determine if the frame type is a "Control" frame. If "Yes", 
the routine proceeds to step 602 to determine if the frame subtype is either an 
"Acknowledgement (ACK)" or "Clear To Send (CTS)" frame. If "Yes", then it proceeds to 
step 603 to set the variable <c DestAddr" to the contents of "Addressl" field 32. The routine 
then proceeds to step 604 to determine if the transmitter address is known. The transmitter 
address for "ACK" and "CTS" frames can not be determined from the contents of the frame, 
because these frames do not cany the Address2 field 34. If the software inside the Network 
Interface Card (NIC) 81 can determine the address of transmitting station for these frame types 
it sets the variable "bTransmitteAddressKnown" to true and sets the contents of the 
'TmphedTransmitterAddress" variable to the address of the transmitting station. The details of 
determining the transmitter address are beyond the scope of this invention, and are covered by 
the above-indicated Related Application Serial No. 09/875,544. If the transmitter address is 
known the routine proceeds to step 605 to set the variable "SrcAddr" to the value stored in the 
variable *TmpliedTransmitterAddress". If the result of step 604 is "No", then the variable 
"SrcAddr" is set to NULL at step 606. If the result of step 602 is "No", the routine proceeds to 
step 608 to set the "DestAddr" and "SrcAddr" variable to the contents of "Addressl" and 
"Address2" fields 32 and 34 respectively. If the frame type is not a "Control" frame at step 
601, the routine proceeds to step 607 to determine if the frame type is a "Management" frame. 
If "Yes", it proceeds to step 608 to set the "DestAddr" and "SrcAddr" variable to the contents 
of "Addressl" and "Address2" fields 32 and 34 respectively. However, if the frame type is 
not a 'Management' ' frame at step 607, the routine proceeds to step 609 to determine if the 
frame type is a "Data" frame. If "Yes", then it proceeds to step 611 to determine if "ToDS" bit 
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field 48 is set to zero. If "Yes", it sets the "DestAddr" variable to the contents of "Address 1" 
field 32 at step 612. It then proceeds to step 613 to determine if "FromDS" bit field 50 is set 
to zero. If ''Yes", then the routine proceeds to step 614 where it sets the variable "SrcAddr" to 
the contents of "Address2" field 34. If the result of step 613 is "No", it proceeds to step 615 
where it sets the variable "SrcAddr" to the contents of "Address3" field 36. If the "ToDS: bit 
field 48 is not set to zero at step 61 1, the routine proceeds to step 616 where it sets the variable 
"DstAddr" to the contents of the "Address3" field 36. The routine then proceeds to step 617 to 
determine if "ToDS" bit field 48 is set to zero. If "Yes", then it proceeds to step 618 to set the 
variable "SrcAddr" to the contents of the "Address2" field 34. If the result of step 617 is "No", 
then it proceeds to step 619 to set the variable "SrcAddr' 9 to the contents of the "Address4" 
field 38. The routine proceeds to step 620 after it executes the steps 603, 605, 606, 608, 610, 
614, 615, 618, or 619. At step 620, the rtfutine executes the 

Display SourceAndDestinationAddressO routine. The implementation of this routine is 
proprietary to Network Associates, Inc. of Santa Clara, CA., and beyond the scope of this 
invention. However, the output of this function can be seen in Figure 5i. The Scan_802_ll() 
terminates at step 621. 

As shown Figure 7, the program executes the Format_802_l l_Summary() routine 304 
generally shown in Figure 3. The Format_802_l l_Summary() routine is responsible for 
detennining and displaying a short concise summary information about the frame. After the 
initialization step 304, the routine proceeds to step 701 where it initializes a string to be used 
as the summary line. It also formats the data rate and the signal strength level as determined by 
the Network Interface Card(NIC) 81. The routine then proceeds to step 702 where it formats 
the name of the frame subtype according to the corresponding bit values listed in Table 1. It 
then proceeds to step 703 to determine if the "WEP" bit field 60 is set to one. If "Yes", it adds 
the "WEP" string to the summary line at step 704. It then proceeds to step 705 to determine if 
the "Retry" bit field 54 is set to one. If "Yes", then it adds to the summary line a "Retry" 
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string. The details of formatting the summary line string are beyond the scope of this 
invention. Some sample summary lines are shown in Figure 52. The 
Format_802_l l_SummaryO routine terminates at step 707. 

With reference to Figure 8, the program executes the Format_802_l l_Detail() routine 
(step 305 of Figure 3) as denoted by steps 801 to 807. The role of this routine 305 is to decode 
the information contained in each frame in detail, and to display it to the user. Upon initiation 
of step 305, the Format_802_l l_Detail0 routine is activated. The routine then proceeds to 
step 801 to determine if the frame type is a "Management: frame. If "Yes", the routine 
proceeds to step 802 to execute the FormatCTRLDetailO subroutine as described in greater 
detail in the flow chart of Figure 9. If the frame type is not "Managemenf ' frame at step 801 
the routine proceeds to step 803 to determine if the frame type is a "Control" frame. If "Yes", 
the routine proceeds to step 804 to execute the FormatDATADetailO subroutine as described 
in greater detail in the flow chart of Figure 20. If "No", then it proceeds to step 805 to 
detennine if the frame type is "Data" frame. If "Yes", it proceeds to step 806 where it executes 
execute the FormatControIDetailO subroutine as described in greater detail in the flow chart of 
Figure 25. The Format_802_l lJDetailO routine terminates at step 807. 

With reference to Figure 9, the program executes the FormatManagementDetailO 
subroutine(step 802 of Figure 8) as denoted by steps 901 to 909. The role of this routine is to 
decode the information contained in management frames in detail, and to display it to the user. 
Upon initiation of step 802, the FormatManagementDetailO routine is activated. The routine 
then proceeds to step 901, where it executes the DisplayPhysicalLayerlnformationO routine to 
display the physical layer related information determined by the Network Interface Card (NIC) 
81 as described in detail by the flowchart of Figure 27. The routine then proceeds to step 902 
to execute the DisplayFrameControlFieldO routine as described in detail by the flowchart of 
Figure 28. The routine proceeds to step 903 where it displays the contents of the duration field 
30. It treats the contents of the duration field 30 as a little-endian unsigned integer of two 
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octets in length. The value of c< Duration" field 30 corresponds in microseconds that the 
medium is reserved by the sending station The detail implementation of displaying the 
contents of the "Duration" field 30 is beyond the scope of this invention. The routine then 
proceeds to step 904 where it displays the destination address by executing the 
DisplayDestinationAddressO routine as described in detail by the flowchart of Figure 29. The 
routine executes the DisplaySourceAddressO routine at step 905 as described in detail by the 
flowchart of Figure 30. The routine then proceeds to step 906 to execute the DisplayBSSIDO 
routine as described in detail by the flowchart of Figure 31 . The routine then proceeds to step 
907 where it displays the fragment and sequence numbers by executing the 
DisplaySequenceControlFieldO routine as described in detail by the flowchart of Figure 34. It 
then proceeds to step 908 to display the information specific to each frame subtype by 
executing the FormatMangementF rameSUbtypeO as described in detail by the flowchart of 
Figure 10. 

As shown Figure 10, the program executes the FonnatManagementFrameSubtypeO 
routine 908 generally shown in Figure 9. The task of this routine is to decode and display the 
information contained in the frame body 24 section of management frame subtypes. The 
routine is activated upon initiation of Step 908,. and it proceeds to step 1001 to determine if the 
frame subtype is a "Association Request" frame. If "Yes", then the routine proceeds to step 
1002 to execute the DisplayAssociationRequestFrameDetailO routine as described in detail by 
the flowchart of Figure 11. If "No", then the routine proceeds to step 1003 to determine if the 
frame subtype is a "Reassociation Request" frame. If "Yes", then it executes the 
DisplayReassociationRequestFrameDetailO routine at step 1004. The 

DisplayReassociationRequestFrameDetailO routine is described in detail by the flowchart of 
Figure 12. If the result of step 1003 is "No", then the routine proceeds to step 1005 to 
determine if the frame subtype is either an "Association Response" or "Reassociation 
Response" frame. If "Yes", the routine proceeds to step 1006, where it executes the 



32 



WO 03/025597 



PCT7US02/29303 



DisplayRe_associationResponseFrameDetail() routine as described in detail by the flowchart 
of Figure 13. If "No", then the routine proceeds to step 1007 to determine if the frame subtype 
is a "Probe Request" frame. If "Yes", the routine proceeds to step 1008, where it executes the 
DisplayProbeRequestFrameDetailO routine as described in detail by the flowchart of Figure 
14. If the result of step 1007 is "No", then the routine proceeds to step 1009 to determine if the 
frame subtype is a "Probe Response" frame. If "Yes", the routine proceeds to step 1010 to 
execute a DisplayProbeResponseFrameDetailO routine as described in detail by the flowchart 
of Figure 15. If the frame subtype is not a "Probe Response" at step 1009, the routine proceeds 
to step 101 1 to determine if the frame subtype is a "Beacon" frame. If "Yes", the routine 
proceeds to step 1012, where it executes the DisplayBeaconFrameDetailO routine as described 
in detail by the flowchart of Figure 16. If "No" at step 1011, the routine proceeds to step 1013 
to determine if the frame subtype is a "Disassociation" frame. If "Yes", then it proceeds to step 
1014 to execute the DisplayDisassociationFrameDetailO routine as described in detail by the 
flowchart of Figure 17. If "No", then it proceeds to step 1015 to determine if the frame 
subtype is a "Authentication" frame. If "Yes", then the routine proceeds to step 1016, where it 
executes the DisplayAuthenticationFrameDetailO routine as described in detail by the 
flowchart of Figure 18. If the result of step 1015 is "No", then the routine proceeds to step 
1017 to determine if the frame type is a "Deauthentication" frame. If "Yes", then it proceeds to 
step 1018 to execute the DisplayDeauthenticationFrameDetailO routine as described in detail 
by the flowchart of Figure 19. The FormatMangementFrameSubtypeO routine terminates at 
step 1019. 

With reference to Figure 1 1, the program executes the 
DisplayAssociationRequestFrameDetailO routine (step 1002 of Figure 10) as denoted by the 
steps 1 101 to 1 107. The role of this routine is to decode and display the information contained 
in the frame body field 24 of the "Association Request" management frame subtype. Upon 
initiation of step 1002, the DisplayAssociationRequestFrameDetailQ routine is activated. The 
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routine then proceeds to step 1 101 to execute the DisplayCapabilitylnformationElementO 
routine as described in detail by the flowchart of Figure 35. It then proceeds to step 1 102 to 
display the contents of the "Listen Interval" field 4408. Listen interval is 2 octets in length. 
This field is used to indicate to the Access Point how often a station wakes to listen to the 
Beacon management frames. It is expressed in units of Beacon interval. The routine then 
proceeds to step 1 103 to execute the DisplaySSIDInfonnationElementO routine as described 
in detail by the flowchart of Figure 36. The routine then proceeds to step 1 104 to execute the 
DisplaySupportedRatesInformationElementO routine as described in detail by the flowchart of 
Figure 37. The routine then proceeds to step 1 105 to determine if there is an unknown 
information element at the end of the frame. If 54 Yes", then it proceeds to step 1 106 to execute 
the DisplayUnknownlhformatioiiEIementO routine as described in detail by the flowchart of 
Figure 38. The DisplayAssociationRequestFrameDetailO routine terminates at step 1107, from 
Step 1 106, or from Step 1 105 if "No." Display of a typical "Association Request" frame body 
is shown in Figure 53. 

With reference to Figure 12, the program executes the 
DisplayReassociationReqnestFrameDetailO routine (step 1004 of Figure 10) as denoted by the 
steps 1201 to 1208. The role of this routine is to decode and display the information contained 
in the frame body field 24 of the "Reassociation Requesf • management frame subtype. Upon 
initiation of step 1004, the DisplayReassociationRequestFrameDetailO *s activated. The 
routine then proceeds to step 1201 to execute the DisplayCapabilitylnformationElementO 
routine as described in detail by the flowchart of Figure 35. It then proceeds to step 1202 to 
display the contents of the "Listen Interval" field 4408. Listen interval is 2 octets in length. 
This field is used to indicate to the Access Point how often a station wakes to listen to the 
Beacon management frames. It is expressed in units of Beacon interval. The routine then 
proceeds to step 1203 to display the MAC address of the current Access Point. The program 
displays the current AP address field 4508 by calling the DisplaySourceAddressQ routine of 
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Figure 30 with appropriate parameters. The routine then proceeds to step 1204 to execute the 
DisplaySSffilhfonnationElementO routine as described in detail by the flowchart of Figure 36. 
The routine proceeds to step 1205 to execute the DisplaySupportedRatesInfonnationElementO 
routine as described in detail by the flowchart of Figure 37. The routine then proceeds to step 
1206 to determine if there is an unknown information element at the end of the frame. If 
"Yes", then it proceeds to step 1207 to execute the DisplayUnknownlnfonnationElementO 
routine as described in detail by the flowchart of Figure 38. The 

DisplayReassociationRequestFrameDetailO routine terminates at step 1208. Display of a 
typical "Ressociation Request* * frame body is shown in Figure 54. 

With reference to Figure 13, the program executes the 
DisplayRe_associationResponseFrameDetailO routine (step 1006 of Figure 10) as denoted by 
the steps 1301 to 1307. The role of this routine is to decode and display the information 
contained in the frame body field 24 of the "Association Response " and "Reassociation 
Response" management frame subtypes. Upon initiation of step 1006, the 
DisplayRe_AssociationResponseFrameDetailO routine is activated. The routine then proceeds 
to step 1301 to execute the DisplayCapabihtylnfonnationElementO routine as described in 
detail by the flowchart of Figure 35. It then proceeds to step 1302 to display the contents of the 
"Status Code" field 4506. The status code field is 2 octets in length. The routine displays the 
status code according to the code values shown in Table 3. The routine then proceeds to step 
1303, where it displays the contents of the "Association ID" field 4504 as an unsigned integer 
of 2 octets in length at step. The two most significant bits of the association ID field 4504 
must be set to ones. The association ID should be between 1 and 2007. The routine then 
proceeds to step 1304 to execute the DisplaySupporiedRatesInformationElementO routine as 
described in detail by the flowchart of Figure 37. The routine then proceeds to step 1305 to 
determine if there is an unknown information element at the end of the frame. If "Yes", then it 
proceeds to step 1306 to execute the DisplayUnlmownMbrmationElementO routine as 
described in detail by the flowchart of Figure 38. The 
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DisplayRe_associationResponseFrameDetail() routine terminates at step 1307, from Step 
1306, or from Step 1305 if "No." Display of a typical "Association Response** frame body is 
shown in Figure 55. 

With reference to Figure 14, the program executes the 
DisplayProbeRequestFrameDetailO routine (step 1008 of Figure 10) as denoted by the steps 
1401 to 1405. The role of this routine is to decode and display the information contained in the 
frame body field 24 of the "Probe Request" management frame subtype. Upon initiation of 
step 1008, the DisplayProbeRequestFrameDetailO routine is activated. The routine then 
proceeds to step 1401 to execute the DisplaySSIDInfonnatioiiElementO routine as described 
in detail by the flowchart of Figure 36. It then proceeds to step 1402 to execute the 
DisplaySupportedRatesiofonnationElementO routine as described in detail by the flowchart of 
Figure 37. The routine then proceeds to step 1403 to determine if there is an unknown 
information element at the end of the frame. If "Yes", then it proceeds to step 1404 to execute 
the DisplayUnknownlnformationElementO routine as described in detail by the flowchart of 
Figure 38. The DisplayProbeRequestFrameDetailO routine terminates at step 1405 from Step 
1404, or from Step 1403 if "No." Display of a typical "Probe Request" frame body is shown 
in Figure 56. 



Meaning 



Successiul " — — . 

Unspecified failure 

Reserved 

Cannot support all requested capabilities in the Capability Information 
Field 

Reassocitaion denied due to inability to confirm that association exists 
Association denied due to reason outside of D3EE802. 1 1 standard 
Responding station does not support the specified authentication 
algorithm 

Received an Authentication frame with authentication transaction 
sequence number out of expected sequence 
Authentication rejected because of challenge failure 
Authentication rejected due to timeout waiting for next frame in 
sequence 
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Association denied because Access Point is unable to handle additional 
associated stations 

Association denied due to requesting station not supporting all of the 
data rates in the Basic Service Set Basic Rate Set 
Association denied due to requesting station not supporting Short 
Preamble option 

Association denied due to requesting station not supporting PBGC 
Modulation option 

Association denied due to requesting station not supporting Channel 
Agility option 
Reserved 

Table 3. Status codes 

With reference to Figure 15, the program executes the 
DisplayProbeResponseFrameDetailO routine (step 1010 of Figure 10) as denoted by the steps 
1501 to 151 1. The role of this routine is to decode and display the information contained in the 
frame body field 24 of the << Probe Respohse" management frame subtype. Upon initiation of 
step 1010, the DisplayProbeResponseFrameDetailO routine is activated. The routine then 
proceeds to step 1501 to display the 'Timestamp" field 4602 of Figure 46A. The 'Timestamp" 
field 4602 is 8 octets long. The routine treats the time stamp number as an 8 octet unsigned 
little endian integer. It then proceeds to step 1502 to display the 'Beacon Interval" field 4406. 
The <f Beacon Interval" field is 2 octets long. It represents the number of time units between 
target beacon transmission times. The routine then proceeds to step 1503, where it executes the 
DisplayCapabiUlylriformationElementO routine as described in detail by the flowchart of 
Figure 35. It then proceeds to step 1504 to execute the the DisplaySSIDInformationElementO 
routine as described in detail by the flowchart of Figure 36. It then proceeds to step 1505 to 
execute the DisplaySupportedRatesInformationElementO routine as described in detail by the 
flowchart of Figure 37. The routine proceeds to step 1506 to execute the 
IMsplayDSPaimneterSetlnformationElementO routine as described in detail by the flowchart 
of Figure 39. If the frame contains a "CF Parameter Set" infpnnation element as transmitted 
by Access Points supporting a Point Coordination Function, the routine then proceeds to step 
1507 to execute the DisplayCFParameterSetlhfoimationElementO routine as described in 
detail by the flowchart of Figure 40. The next element in the probe response frame is the 
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'Independent Basic Service Set (IBSS) parameter set" if the sending station is operating in an 
Independent Basic Service Set. The routine then executes the 

DisplaylBSSParaineterSelinfonnationElementO routine at step 1508 as described in detail by 
the flowchart of Figure 41. The routine then proceeds to step 1509 to determine if there is an 
unknown information element at the end of the frame. If "Yes", then it proceeds to step 1510 
to execute the DisplayUiilmownlnfonnationElementO routine as described in detail by the 
flowchart of Figure 38. The DisplayProbeResponseFrameDetail 0 routine terminates at step 
1511 from Step 1510, or from Step 1509 if ss No." Display of a typical "Probe Response" 
frame body is shown in Figure 57. 

With reference to Figure 16, the program executes the DisplayBeaconFrameDetailO 
routine (step 1012 of Figure 10) as denoted by the steps 1601 to 16412. The role of this routine 
is to decode and display the information contained in the frame body field 24 of the "Beacon" 
management frame subtype. Upon initiation of step 1012, the DisplayBeaconFrameDetail 0 
routine is activated. The routine then proceeds to step 1601 to display the 'Timestamp" field 
4602 of Figure 46 A. The 'Timestamp" field 4602 is 8 octets long. The routine treats the time 
stamp number as an 8 octet unsigned little endian integer. It then proceeds to step 1602 to 
display the "Beacon Interval" field 4406. The "Beacon Interval" field is 2 octets long. It 
represents the number of time units between target beacon transmission times. The routine 
then proceeds to step 1603, where it executes the DisplayCapabilitylnformationElementO 
routine as described in detail by the flowchart of Figure 35. It then proceeds to step 1604 to 
execute the DisplaySSIDLxformationElementO routine as described in detail by the flowchart 
of Figure 36. It then proceeds to step 1605 to execute the 

DisplaySupportedRatesInformatioziElementO routine as described in detail by the flowchart of 
Figure 37. The routine proceeds to step 1606 to execute the 

DisplayDSParameterSetlnformationElementO routine as described in detail by the flowchart 
of Figure 39. If the frame contains a "CF Parameter Set" information element as transmitted 
by Access Points supporting a Point Coordination Function, the routine then proceeds to step 
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1607 to execute the DisplayCFParameterSetl^ormatioiiElemeiitO routine as described in 
detail by the flowchart of Figure 40. The next element in the beacon frame is the "Independent 
Basic Service Set (EBSS) parameter sef * if the sending station is operating in an Independent 
Basic Service Set The routine then executes the 

DisplayroSSParameterSetlafonnationElementO routine at step 1608 as described in detail by 
the flowchart of Figure 41. The routine proceeds to step 1609 to execute the 
DisplayTIMParameterSellnfonnationElementO routine as described in detail by the flowchart 
of Figure 42. The routine then proceeds to step 1610 to determine if there is an unknown 
information element at the end of the frame. If "Yes", then it proceeds to step 161 1 to execute 
the DisplayUiilmownlnfonnationElementO routine as described in detail 
by the flowchart of Figure 38. The DisplayBeaconFrameDetail 0 routine terminates at step 
1612 from Step 1611, or from Step 1610-if "No." Display of a typical "Beacon" frame body is 
shown in Figure 58. 

With reference to Figure 17, the program executes the 
DisplayDisassociationFrameDetailO routine (step 1014 of Figure 10) as denoted by the steps 
1701 to 1704. The role of this routine is to decode and display the information contained in the 
frame body field 24 of the "Disassociation" management frame subtype. Upon initiation of 
step 1014, the DisplayDisassociationFrameDetailO routine is activated. The routine then 
proceeds to step 1701 to display the contents of the "Reason Code" field 4502. The Reason 
Code is an unsigned number that is 2 octets long. The routine displays a message 
corresponding to the "Reason Code" field 4502 according to the values listed in Table 4. The 
routine then proceeds to step 1702 to determine if there is an unknown information element at 
the end of the frame. If "Yes" then it proceeds to step 1703 to execute the 
DisplayUnknownlnformationElementO routine as described in detail by tihe flowchart of 
Figure 38. The DisplayDisassociationFrameDetailO routine terminates at step 1704 from Step 
1703, or from Step 1702 if "No." Display of a typical "Disassociation" frame body is shown 
in Figure 59. 
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Reason 


Meaning 


code * 




0 
1 
2 
3 


Reserved 

Unspecified reason 

Previous authentication no longer valid 

Deauthenticated because sending station is leaving (or has left) IBSS or 


4 
5 


ESS 

Disassociated due to inactivity 

Disassociated because Access Point is unable to handle all currently- 


6 
7 
8 
9 


associated stations 

Class 2 frame received from nonauthenticated station 
Class 3 frame received from nonassociated station 
Disassociated because sending station is leaving (has left) BSS 
Station requesting (re)association is not authenticated with responding 


10 - 65535 


station 
Reserved 



Table 4. Reason codes 



With reference to Figure 18, the program executes the 
DisplayAuthenticationtFrameDetailO routine (step 1016 of Figure 10) as denoted by the steps 
1801 to 1814. The role of this routine is to decode and display the information contained in the 
frame body field 24 of the "Authentication" management frame subtype. Upon initiation of 
step 1016, the DisplayAuthenticationtFrameDetailO routine is activated. The routine then 
proceeds to step 1801 to determine if the "WEP" bit field 60 is set to one. If "Yes", the frame 
is originally encrypted and the routine proceeds to step 1802 to display the contents of the 
WEP-IV field 66 (See Figure 2C) of length 4 octets. The first three octets contain the 
initialization vector for the decoding engine. The two most significant bits of the last octet 
holds the key number used to encrypt the data. The remaining bits of the last octet are reserved 
for future use. The routine then proceeds to step 1803 to determine if the frame is decrypted. If 
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"No", then the routine proceeds to step 1804 to display the contents of the encrypted data. The 
routine then proceeds to step 1805 to display the contents of the WEP-ICV field 70. The WEP- 
ICV field is 4 octets in length and carries the 'Integrity Check Value" of the encrypted data. 
The routine then proceeds to termination step 1814. If the frame is not originally encrypted 
(step 1801) or the frame is decrypted (step 1803) the routine proceeds to step 1806 to display 
the contents of the "Authentication Algorithm Number" field 4402. Authentication algorithm 
number is an unsigned number that is 2 octets long. The current allowed values are 0, which 
corresponds to Open System Authentication; and 1, which corresponds to Shared Key 
Authentication. The routine proceeds to step 1807 to display the contents of the 
"Authentication Transaction Sequence Number" field 4404. The authentication transaction 
sequence number is an unsigned number that is 2 octets long. This number is used to identify 
the frame number used in the authentication exchange sequence. It proceeds to step 1 808 to 
display the contents of the "Status Code" field 4506. The status code field is 2 octets in length. 
The routine displays the status code according to the code values shown in Table 3. The 
routine proceeds to step 1809 to determine if the "Authentication Algorithm Number " is equal 
to 1 (Shared key), and the transaction sequence number is either 2 or 3. If **Yes", the routine 
proceeds to step 1810 to execute the Display OiallengeTextlnfoxmationElementO routine as 
described in detail by the flowchart of Figure 43. The routine then proceeds to step 181 1 to 
determine if there is an unknown information element at the end of the frame. If "Yes", then it 
proceeds to step 1812 to execute the DisplayUnknownlnformationElementO routine as 
described in detail by the flowchart of Figure 38. The routine then proceeds to step 1813 to 
determine if the frame is a decrypted frame. If "Yes", the routine proceeds to step 1805 to 
display the contents of the WEP-ICV field 70. The DisplayAuthenticationtFrameDetail 0 
routine terminates at step 1814 either from Step 1805, or from Step 1813 if "No " 
Authentication frames are exchanged between the stations to authenticate title requesting 
station by the responding station. The authentication transaction sequence transaction number 
depends on the frame direction. Display of a typical "Authentication" frame with transaction 
sequence number 2 is shown in Figure 60. 
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With reference to Figure 19, the program executes the 
DisplayDeauthenticationFrameDetailO routine (step 1018 of Figure 10) as denoted by the 
steps 1901 to 1904. The role of this routine is to decode and display the information contained 
in the frame body field 24 of the "Deauthentication" management frame subtype. Upon 
initiation of step 1018, the DisplayDeauthenticatiohFrameDetail 0 routine is activated. The 
routine then proceeds to step 1901 to display the contents of the 4C Reason Code** field 4502. 
The Reason Code is an unsigned number that is 2 octets long. The routine displays a message 
corresponding to the <( Reason Code" field 4502 according to the values listed in Table 4.The 
routine then proceeds to step 1902 to determine if there is an unknown information element at 
the end of the frame. If "Yes", then it proceeds to step 1903 to execute the 
DisplayUnknownlnfoimationElementO routine as described in detail by the flowchart of 
Figure 38. The DisplayDeauthenticationJFrameDetailO routine terminates at step 1904 from 
step 1903, or from step 1902 if "No". Display of a typical "Deauthentication" frame body is 
shown in Figure 62. 

With reference to Figure 20, the program executes the FormatCTRLDetailO routine 
(step 804 of Figure 8) as denoted by the steps 2001 to 201 1. The role of this routine is to 
decode and display the information contained in the "Control" frame type. Upon initiation of 
step 804, the FormatCTRLDetailO routine is activated. The routine then proceeds to step 
2001, where it executes the DisplayPhysicalLayerlnfonnationO routine to display the physical 
layer related information determined by the Network Interface Card (NIC) 81 (see Figure 1) as 
described in detail by the flowchart of Figure 27. The routine proceeds to step 2002 to execute 
the DisplayFrameControlFieldO routine as described in detail by the flowchart of Figure 28. It 
then proceeds to step 2003 to determine if the frame subtype is a 'Tower Save (PS) - Poll" 
frame. If "Yes", the routine proceeds to step 2004 to execute the FonnatPS_POLLDetail() as 
described in detail by the flowchart of Figure 21. If "No", the routine then proceeds to step 
2005 to determine if the frame subtype is a "Request To Send (RTS)" frame. If "Yes", the 
routine proceeds to step 2006 to execute the FormatRTSDetail 0 as described in detail by the 
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flowchart of Figure 22. If the result of step 2005 is "No", the routine proceeds to step 2007 to 
determine if the frame subtype is either a "Clear To Send (CTS)" or an "Acknowledgement" 
frame. If "Yes", the routine proceeds to step 2008 to execute the FomatCTS_ACKDetail()as 
described in detail by the flowchart of Figure 23. If the result of step 2007 is "No", the routine 
then proceeds to step 2009 to determine if the frame subtype is either a "Contention Free (CF) 
- End" or a "CF - End + CF-Ack" frame. If "Yes", the routine proceeds to step 2010 to 
execute the FonnatCF_END_ACKDetailO as described in detail by the flowchart of Figure 
24. The FonnatCTRLDetailO routine terminates at step 2011 from Step 2010, or from Step 
2009 if "No." 

As shown in Figure 21, the program executes the FonnatPSJPOLLDetailO subroutine 
2004 generally shown in Figure 20. The task of this routine is to decode and display the 
information contained in the "Power Save (PS) - Poll" frame. The routine is activated at step 
2004, and it proceeds to step 2101 to determine if the two most significant bits of the 
"Association ID" field 30 are not set to one, because the IEEE802.il standard requires these 
bits to be set to one. If tc Yes", then the routine proceeds to step 2102 where it displays a 
warning message "2 MSB bits of Association ID field should be 1". If the result of step 2101 
is "No", then it proceeds to step 2103 to check if the 2 octet little endian number in the 
"Association ID" field 30 is between 1 and 2007. If "Yes", then the routine displays the 
contents of the "Association ID" field 30 as an unsigned integer of two octets in length at step 
2104. If the result of step 2103 is "No", then the routine displays a warning message 
"Association ID should be in range 1 to 2007" at step 2105. The routine then proceeds to step 
2106 to execute the DisplayBSSE>0 routine as described in detail by the flowchart of Figure 
31. It then proceeds to step 2107, where it executes the DisplayTransmitterAddressO routine 
as described in detail by the flowchart of Figure 33. The FonnatPSJPOLLDetailO routine 
terminates at step 2108. Display of a typical 'Tower Save (PS) - Poll" frame is shown in 
Figure 62. 
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As shown Figure 22, the program executes the FonnatRTSDetailO subroutine 2006 
generally shown in Figure 20. The task of this routine is to decode and display the 
information contained in the "Request To Send (RTS)" frame. The routine is activated at step 
2006, and it proceeds to step 2201 where it displays the contents of the duration field 30. It 
treats the contents of the duration field as a little-endian unsigned integer of two octets in 
length. The value in 'Duration" field 30 corresponds to the amount of time in microseconds 
that the medium is reserved by the sending station. The routine then proceeds to step 2202 to 
execute the DisplayReceiverAddressO routine as described in detail by the flowchart of Figure 
32. It then proceeds to step 2203, where it executes the DisplayTransmitterAddressO routine 
as described in detail by the flowchart of Figure 33. The FonnatRTSDetailO routine terminates 
at step 2204. Display of a typical Request To Send (RTS)" frame is shown in Figure 63. 

As shown Figure 23, the program executes the FormatCTS_ACKDetailO subroutine 
2008 generally shown in Figure 20 via initiation step 2300. The task of this routine is to 
decode and display the information contained in the "Clear To Send (CTS)" and 
"Acknowledgement (ACK)" frames. The routine is activated at step 2008, and it proceeds to 
step 2301 where it displays the contents of the duration field 30. It treats the contents of the 
duration field as a little-endian unsigned integer of two octets in length. The value in 
"Duration" field 30 corresponds to the amount of time in microseconds that the medium is 
reserved by the sending station. The routine then proceeds to step 2302 to execute the 
DisplayReceiverAddressO routine as described in detail by the flowchart of Figure 32. The 
routine then proceeds to step 2303 to determine if the transmitter address is known. The 
transmitter address for "ACK" and "CTS" frames cannot be determined from the contents of 
the frame, because these frames do not carry the Address2 field 34. If the software inside the 
Network Interface Card (NIC) 81 can determine the address of the transmitting station for 
these frame types, it sets the variable <c bTransmitteAddressKnown" to "TRUE", and sets the 
contents of the "EmpliedT ransmitterAddress" variable to the address of the transmitting 
station. The details of determining the transmitter address are beyond the scope of this 
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invention, and is covered by co-pending Serial No. 09/875,544 shown above as a Related 
Application, If the transmitter address is known the routine proceeds to step 2304, where it 
executes the DisplayTransmitterAddressO routine as described in detail by the flowchart of 
Figure 33. The FormatCTS_ACKDetail() routine terminates at step 2305 from step 2304, or 
from step 2303 if "No." Display of a typical "Acknowledgement (ACK)" and "Clear To Send 
(CTS)" frames are shown in Figure 64 and Figure 65 respectively. 

As shown in Figure 24, the program executes the FormatCF JEND_ACKDetailO 
subroutine 2010 generally shown in Figure 20. The task of this routine is to decode and 
display the information contained in the "Contention Free (CF) - End" and "CF - End + CF- 
Ack" frames. The routine is activated at step 2010, and it proceeds to step 2401, where it 
displays the contents of the duration field 30. It treats the contents of the duration field as a 
little-endian unsigned integer of two octets in length. The value in "Duration" field 30 
corresponds to the amount of time in microseconds that the medium is reserved by the sending 
station. The routine then proceeds to step 2402 to execute the DisplayReceiverAddressO 
routine as described in detail by the flowchart of Figure 32. It then proceeds to step 2403, 
where it executes the DisplayBSSIDO routine as described in detail by the flowchart of Figure 
31. The FormatCFJEND^ACKDetail 0 routine terminates at step 2404. Display of a typical 
"Contention Free (CF) - End" frame is shown in Figure 66. 

With reference to Figure 25, the program executes the FormatDATADetail 0 routine 
(step 806 of Figure 8) as denoted by the steps 2501 to 2528. The role of this routine is to 
decode and display the information contained in the "Data" frame type. Upon initiation of step 
806, the FormatDATADetail 0 routine is activated The routine then proceeds to step 2501, 
where it executes the DisplayPhysicalLayerlnformationO routine to display the physical layer 
related information determined by the Network Interface Card (NIC) 81 as described in detail 
by the flowchart of Figure 27. The routine proceeds to step 2502 to execute the 
DisplayFrameControlFieldO routine as described in detail by the flowchart of Figure 28. The 
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routine proceeds to step 2503, where it displays the contents of the duration field 30. It treats 
the contents of the duration field as a little-endian unsigned integer of two octets in length. The 
value of "Duration" field 30 corresponds to the amount of time in microseconds that the 
medium is reserved by the sending station. The routine then proceeds to step 2504 to 
determine if the "ToDS" bit field 48 is set to zero. If "Yes", then it proceeds to step 2505 to 
execute the DisplayDestmationAddressO routine as described in detail by the flowchart of 
Figure 29. It then proceeds to step 2506 to determine if the "FromDS" bit field 50 is set to 
zero. If "Yes", then the routine proceeds to step 2507 to execute the DisplaySourceAddressO 
routine as described in detail by the flowchart of Figure 30. It then proceeds to step 2508 to 
execute the DisplayBSSIDO routine as described in detail by the flowchart of Figure 3 1 . The 
routine then proceeds to step 251 1. If the "FromDS" bit field 50 is not set to zero in step 2506, 
then the routine proceeds to step 2509 to -execute the DisplayBSSIDO routine as described in 
detail by the flowchart of Figure 31. The routine proceeds to step 2520 to execute the 
DisplaySourceAddressO routine as described in detail by the flowchart of Figure 30. The 
routine then proceeds to step 251 1 to execute the DisplaySequenceControlFieldO as described 
in detail by the flowchart of Figure 34. The execution then moves to step 2522. If the "ToDS" 
bit field 48 is not set to zero at step 2504 the routine proceeds to step 2512 to determine if the 
"FromDS" bit field 50 is se t to zero. If 'Yes", then the routine proceeds to step 25 13 to 
execute the DisplayBSSIDO routine as described in detail by the flowchart of Figure 3 1 . The 
execution then moves to step 2514 to invoke the DisplaySourceAddressO routine as described 
in detail by the flowchart of Figure 30. The routine then invokes at step 2515 the 
DisplayDestmationAddressO routine as described in detail by the flowchart of Figure 29. The 
next step 2516 is the execution of the DisplaySequenceControlFieldO routine as described in 
detail by the flowchart of Figure 34. The routine moves the execution to step 2522. If the 
'TromDS" bit field 50 is not set to zero on step 2512, the routine then proceeds to step 2517 
where it executes the DisplayReceiverAddressO routine as described in detail by the flowchart 
of Figure 32. It then proceeds to step 2518 to execute the DisplayTransmitterAddressO routine 
as described by the flowchart of Figure 33. It then moves to step 2519 to execute 
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DisplayDestinationAddressO routine as described by the flowchart of Figure 29. The routine 
proceeds to step 2520 to execute the DisplaySequenceControlFieldO routine as described by 
the flowchart of Figure 34. The routine next executes DisplaySourceAddressO at step 2521 as 
described by the flowchart of Figure 30. The routine then proceeds to step 2522 to determine if 
the data frame subtype is one of the "Null Function (No data)", "Contention Free (CF) - 
Acknowledgement (No Data)", "Contention Free (CF) - Poll(No Data)" or ""Contention Free 
(CF) - Acknowledgement + CF-Poll(No Data)" frames. If "Yes", the routines terminates at 
step 2528, because these frame subtype do not carry any data in the frame body field 24. If 
"No", then the routine proceeds to step 2523 for further decoding of the data frame. At step 
2523 the routine determines if the "WEP" bit field 60 is set to one. If "No" the routine 
terminates. If the result of step 2523 is "Yes", the routine proceeds to step 2524 display the 
contents of the WEP -IV field 66 of length 4 octets. The first three octets contain the 
initialization vector for the decoding engine. The two most significant bits of the last octet 
holds the key number used to encrypt the data The remaining bits of the last octet are reserved 
for future use. The routine then proceeds to step 2525 to determine if the contents of the 
originally encrypted frame is not decrypted by the Network Interface Car (NIC) 81. If "Yes" 
the routine then proceeds to step 2526 to execute the DisplayEncryptedDataO routine which 
shows the number of encrypted octets. The routine then proceeds to step 2527 both from steps 
2525 and 2526 to display the contents of the WEP-ICV field 70. The WEP-ICV field is 4 
octets in length carries the "Integrity Check Value" of the data frame. The 
FonnatDATADetailO routine terminates at step 2528. The display of a typical encrypted and 
decrypted data frames are shown in Figure 67 and Figure 68 respectively. 

With reference to Figure 26, the program executes the 
PrepareForUpperLayerDecodingO routine (step 306 of Figure 3) as denoted by the steps 2601 
to 2612. The role of this routine is to determine the parameters that will be necessary for upper 
layer decoding to be completed. The routine determines which upper layer decoding 
interpreter will be called next along with which data offset the new decoding routine will start 
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decoding. Upon initiation of step 306, the PrepareForUpperLayerDecodingO routine is 
activated. The routine then proceeds to step 2601 to determine if the frame type is a "Data" 
frame, and whether it was received without a decryption error, because only data frames 
without decryption errors will have valid data. If the result of step 2601 is "Nd", the variable 
"NextLayer" will be set to NULL at step 2602, and the routine proceeds to step 2612 to 
terminate. If the result of step 2601 is "Yes", the routine then proceeds to step 2603 to 
determine if the "WEP" bit field 60 is set to zero. If "Yes", the routine proceeds to step 2604, 
where it sets the variable "DataStart" used by the higher layer interpreter to the length of the 
MAC header of the IBEE802.1 1 wireless standard. The routine then will proceed to step 2608. 
If the "WEP" bit field 60 is not set to zero at step 2603, the routine then proceeds to step 2605 
to determine if the frame is decrypted. If "No", the routine proceeds to step 2606, where the 
variable "NextLayer" will be set to NULL, and the routine proceeds to step 2612 to terminate. 
If the frame is decrypted as determined at step 2605, the routine proceeds to step .2607 where 
the variable "DataStart" is set to the length of the MAC header of the EBEE802.il wireless 
standard plus four. The extra four octets are due to the length of the WEP -IV field 66 as shown 
in Figure 2C. The routine then proceeds to step 2608 to determine if the 2-octet field at the 
location of "DataStart" in the frame is equal to OxFFFF in hexadecimal. If "Y es", then the 
variable "NextLayer" will be set to 'IPX" via step 2609, which corresponds to Novell Internet 
Packet Exchange over Data Link Control layer. The routine then proceeds to step 261 1 . If the 
result of step 2608 is "No", then the routine proceeds to step 2610 where the variable 
"NextLayer" will be set to "LLC", which corresponds to Logical Link Control layer 
encapsulation of the data. Then the routine proceeds to step 261 1 to notify the calling routine 
about the next layer to be called, and where the next layer will start decoding in the frame. The 
PrepareForUpperLayerDecodingO routine terminates at step 2612. 

With reference to Figure 27, the program executes the 
DisplayPhysicalLayerlnformationO routine as denoted by the steps 2700 to 2713. The role of 
this routine is to display the physical characteristics of the frame, determined by the Network 
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Analysis Tool 80 when the frame is captured. The physical characteristics of the frame are 
stored in the capture buffer along with the frame data. The information stored relates to 
characteristics such as frame number in the capture buffer, frame size, frame error if any, radio 
signal strength, the channel that the signal is received, data rate, if the frame is transmitted 
using short physical header, and encryption information such as encryption key used to decode 
the encrypted frame. Upon activation at step 2700, the routine proceeds to step 2701 to display 
the time the frame is captured and the size of the frame in octets. The Network Analysis Tool 
80 can be configured by the user in such a way that the number of octets stored in the capture 
buffer can be limited to a user selected number. This allows the user to capture a lot more 
frames for a fixed size of the capture buffer 83. However, some information at the higher 
layers will be lost when the user wants to analyze the captured frames offline. The routine 
proceeds to step 2702 to determine if the. frame is sliced during the capture. If "Yes", the 
routine proceeds to step 2703 and displays the sliced size of the captured frame. The routine 
proceeds to step 2704 either from step 2703, or from step 2702 if "No," to determine if the 
captured frame contains any error. If "Yes", the routine proceeds to step 2705 to display the 
error information. The error types the frames can have: 

i) Bad CRC (Cyclic Redundancy Check ) 

ii) PLCP (Physical Layer Control Protocol) error 

iii) WEP-ICV (Wired Equivalent Privacy Integrity Value) error 

iv) Undersize frame error 

v) Oversize frame error 

The routine proceeds to step 2706 either from step 2705, or from step 2704 if "No," to 
display the strength of the radio signal in percentage when the frame is received. At step 2707, 
the routine displays the channel number on which the frame is received. At step 2708, the 
routine displays the data rate in terms of Mbits per second. The routine then proceeds to step 
2709 to determine if the frame is transmitted using short physical layer control protocol 
(PLCP) header. If "Yes", the routine proceeds to step 2710, where it displays information to 
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the user that the frame is received with a short PLOP header. It then proceeds to step 271 1, 
either from step 2710, or from step 2709 if "No," to determine if the frame is originally 
encrypted. If "Yes", then the routine proceeds to step 2712 to display the key number used for 
the encryption if it does not have any decryption error. If it has a decryption error then it 
simply displays via step 2712 information that notifies the user that frame was originally 
encrypted. The routine terminates at step 2713, either from steo 2712, or from step 271 1 if 
"No". A typical output of the DisplayPhysicall^yerlnfonnationO routine is shown in Figure 
69. 

With reference to Figure 28, the program executes the DisplayFrameControlFieldO 
routine as denoted by the steps 2800 to 2805. This routine displays the contents of the "Frame 
Control" field 20. The length of the frame control field 20 is 16 bits (2 octets) as shown in 
Figure 2B. Upon activation at step 2800, the routine proceeds to step 2801 to display the 
version number of the protocol as determined by the IEEE802.1 1 standard. The protocol 
version field 42 is 2 bits in length, and resides in the two least significant bits (bits 0 and 1). At 
step 2802, the routine displays the frame type. "Frame Type" field 44 is 2 bits in length and 
resides in the bits B2 and B3. The program displays the frame type according to the bit values 
as shown in Table 1 . The routine then proceeds to step 2803 to display the frame subtype. 
"Frame Subtype" field 46 is 4 bits in length, and it resides in bits B4 through B7. The routine 
displays the frame subtype according to the bit value combinations as shown in Table 1. The 
routine then proceeds to step 2804 to display the contents of the second octet of the "Frame 
Control" field 28. It displays suitable messages depending on the bit values in each bit as 
follows. Bit B8 of the "Frame Control" field corresponds to the "ToDS" bit field 48. "ToDS" 
field 48 is set to one if the frame is destined for the distribution system. Otherwise it is set to 
zero. The bit B9 corresponds to "FromDS" bit field 50. If the frame is from the distribution 
server this bit is set to one, otherwise set to zero. Bit B 10 corresponds to "MoreFrag" bit field 
52. If the current frame is a fragment of a larger frame and there are more fragments to follow 
this bit is set to one. Bit Bl 1 corresponds to "Retry" bit field 54. It is set to one if the current 
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frame is a retry of a previously transmitted frame. Bit B 12 corresponds to the "Pwr Mgmt" bit 
field 56. It is set to one if the sending station will be in the power-save mode. It will be set to 
zero if it will be in active mode. Bit B 13 corresponds to "More Data" bit field 58. It is set to 
one if there are more data destined at the Access Point to a station in power-save mode. It is 
set to zero otherwise. Bit B 14 corresponds to "WEP bit field 60. It is set one if the frame is 
encrypted and set to zero otherwise. Bit B15 of the "Frame Control" field 28 corresponds to 
"Order" bit field 62. It is set to one in any frame that contains data r which is being transferred 
using "Strictly Ordered" service class. After displaying the values of the bits and 
corresponding meaning of the bits the routine terminates at step 2805. A typical output of the 
DisplayFrameControlField 0 routine is shown in Figure 69. 

With respect to Figure 29, the program executes the DisplayDestinationAddressO 
routine as denoted by the steps 2900 to 2907. The role of this routine is to format and to 
display the destination address of the frame. The Medium Access Control (MAC) addresses 
are 6 octets in length. If the address is destined to a single station it is referred to as a 
"Uriicast" address. If the frame is destined to a group of stations it is referred to as "Multicast" 
address. If it is destined to all stations it is called a "Broadcast" address. According to 
EEEE802.il standard if the MAC address field carries all ones (OxFFFFFFFFFFFF in 
hexadecimal) it is a broadcast address. If the least significant bit of the first octet of the MAC 
address is "1", it is a multicast address. Otherwise it is a unicast address. Upon activation at 
step 2900, the routine proceeds to step 2901 to determine if the destination address is a 
broadcast address. If "Yes", it proceeds to step 2902 to display 'BROADCAST" string for the 
address. It then proceeds to step 2906. If the address is not broadcast at step 2901, the routine 
proceeds to step 2903 to determine if the destination address is a multicast address. If "Yes", 
the routine then proceeds to step 2904 to display the string 'Multicast". The routine proceeds 
to step 2906. If the address is not a multicast at step 2903, the routine proceeds to step 2905 to 
display the string "Station" indicating a unicast address. The routine then proceeds to step 
2606 to format and display the destination address. The first 3 octets of any unicast MAC * 
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address are unique to a manufacturer. The routine displays a 6-character abbreviation for the 
first three octets of the MAC address. The remaining octets are printed as hexadecimal 
numbers for each octet in order. The routine terminates at step 2907. A typical output of the 
DisplayDestinationAddressO routine is shown in Figure 70. 

With respect to Figure 30, the program executes the DisplaySourceAddressO routine as 
denoted by the steps 3000 to 3007. The role of this routine is to format and to display the 
source address of the frame. Upon activation at step 3000, the routine proceeds to step 3001 to 
display the string "Station". The routine proceeds to step 3002 to format and display the 
source address. The first 3 octets of any unicast MAC address are unique to a manufacturer. 
The routine displays a 6-character abbreviation for the first three octets of the MAC address. 
The remaining octets are printed as hexadecimal numbers for each octet in order. The routine 
proceeds to step 3003 to determine if the source address is a broadcast address. If tc Yes", it 
proceeds to- step 3004 to display warning message string "(Should not be Broadcast)", because 
the source address cannot be a broadcast address. It then proceeds to step 3007. If the address 
is not broadcast at step 3003, the routine proceeds to step 3005 to determine if the source 
address is a multicast address. If "Yes," it proceeds to step 3006 to display warning message 
string "(Should not be Multicast)", because the source address cannot be a multicast address. 
The routine terminates at step 3007. A typical output of the DisplaySourceAddressO routine is 
shown in Figure 70. 

With respect to Figure 31, the program executes the DisplayBSSIDO routine as 
denoted by the steps 3100 to 3112. The role of this routine is to format and to display the 
Basic Service Set Identification (BSSID) of the frame. Upon activation at step 3100, the 
routine proceeds to step 3101 to determine if the address type in the BSSID field corresponds 
to BSSID of an Access Point. If "Yes", the routine proceeds to step 3102 to display the 
"Station" string, because the BSSID of an Access Point is the same as its MAC address; 
therefore, it cannot be a multicast or broadcast address. The routine proceeds to step 3 103 to 
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format and display the BSSID using the same techniques as the source and destination address. 
The routine proceeds to step 3104 to determine if the address in the BSSID field is a broadcast 
address. If "Yes", step 3 105 is entered, and displays a warning message of "(Should not be 
Broadcast)". The routine proceeds to termination step 3114. If the address is not broadcast at 
step 3104, the routine proceeds to step 3106 to determine if the address is multicast If "Yes", 
step 3107 is entered, and displays a warning message "(Should not be Multicast)". The routine 
proceeds to step 3114. If the BSSID type at step 3101 is not an Access Point BSSID, the 
routine then proceeds to step 3108 to determine if the address type is broadcast. If "Yes", it 
proceeds to step 3109 to display '"BROADCAST". The routine then proceeds to step 3 1 10 to 
format and display the BSSID as if it is an address as described previously. The routine 
proceeds to step 31 14. If the address type is not broadcast at step 3108, the routine proceeds to 
step 3 1 1 1 to determine if the address is multicast. If "Yes", the routine proceeds to step 3 1 12 
to format and display the BSSID as a MAC address. The routine then proceeds to step 3 1 13 to 
. - display a warning message ""(Should not be Multicast)". The routine terminates at step 31 14. 
A typical output of the DisplayBSSIDO routine is shown in Figure 69. 

With respect to Figure 32, the program executes the DisplayReceiverAddressO routine 
as denoted by the steps 3200 to 3207. The role of this routine is to format and to display the 
receiver address of the frame. Upon activation at step 3200, the routine proceeds to step 3201 
to determine if the receiver address is a broadcast address. If 'Yes", it proceeds to step 3202 to 
display "BROADCAST" string for the address. It then proceeds to step 3206. If the address is 
not broadcast at step 3201, the routine proceeds to step 3203 to determine if the receiver 
address is a multicast address. If 'Yes", the routine then proceeds to step 3204 to display the 
string 'Multicast" . The routine proceeds to step 3206. If the address is not a multicast at step 
3203, the routine proceeds to step 3205 to display the string "Station" indicating a unicast 
address. The routine then proceeds to step 3206 to format and display the receiver address. The 
first 3 octets of any unicast MAC address are unique to a manufacturer. The routine displays a 
6-character abbreviation for the first three octets of the MAC address. The remaining octets are 
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printed as hexadecimal numbers for each octet in order. The routine terminates at step 3207. A 
typical output of the DisplayReceiverAddressO routine is shown in Figure 70. 

With respect to Figure 33, the program executes the DisplayTransmitterAddressO 
routine as denoted by the steps 3000 to 3007. The role of this routine is to format and to 
display the transmitter address of the frame. Upon activation at step 3300, the routine proceeds 
to step 3301 to display the string "Station". The routine proceeds to step 3202 to format and 
display the transmitter address. The first 3 octets of any unicast MAC address are unique to a 
manufacturer. The routine displays a 6-character abbreviation for the first three octets of the 
MAC address. The remaining octets are printed as hexadecimal numbers for each octet in 
order. The routine proceeds to step 3303 to determine if the transmitter address is a broadcast 
address. If ''Yes" it proceeds to step 3304 to display warning message string "(Should not be 
Broadcast)", because the transmitter address cannot be a broadcast address. It then proceeds to 
termination step 3307. If the address is not broadcast at step 3003, the routine proceeds to step 

3305 to determine if the transmitter address is a multicast address. If "Yes," it proceeds to step 

3306 to display warning message string "(Should not be Multicast)", because the transmitter 
address cannot be a multicast address, and then proceeds to step 3307. If "No," the routine 
terminates at step 3307. A typical output of the DisplayTransmitterAddressO routine is shown 
in Figure 70. 

With respect to Figure 34, the program executes the DisplaySequenceControlFieldO 
routine as denoted by the steps 3400 to 3405. The role of this routine is to format and to 
display the sequence and the fragment number of the frame. Upon activation at step 3400, the 
routine proceeds to step 3401 to determine the sequence number. The "Sequence Control" 
field 40 is 2 octets in length. The sequence number occupies the twelve most significant bits of . 
the "Sequence Control" field 40. The routine first gets the twelve most significant bits of the 
sequence control field and shifts the result by 4 bits to right. The routine then proceeds to step 
3402 to determine the fragment number which resides in the 4 least significant bits of the 

54 



WO 03/025597 - PCT/US02/29303 



"Sequence Control" field 40. The routine then proceeds to step 3403 to display the sequence 
number, and then to step 3404 to display the fragment number. The routine terminates at step 
3405. A typical output of the DisplaySequenceControlFieldO routine is shown in Figure 69 
and Figure 70. 

With respect to Figure 35, the program executes the 
DisplayCapabilitylnfonnationElementO routine as denoted by the steps 3500 to 3507. The role 
of this routine is to format and to display the capability information field. The capability 
information element is 2 octets in length. The structure of the Capability Information element 
is shown in Figure 46B. Upon activation at step 3500, the routine proceeds to step 3501 to 
display the ESS bit field 4604 (bit 0). If it is set to one it means the station is operating in an 
Extended Service Set It is set to zero otherwise. The routine displays the content of the IBSS 
bit field 4606. The IBSS bit is set to 1 if the station is running in an Independent Basic Service 
Set. It is set to zero otherwise. The routine proceeds to step 3502 to determine if the 
management frame subtype is either an "Association Request* * or "Reassociation Request" 
frame. If "Yes" the routine proceeds to step 3503 to display the contents of the "CF-Pollable" 
and "CF Poll Request" bit fields 4608 and 4610, respectively, according to the bit values as 
shown in Table 5 (see below). If the result of the step 3502 is <£ No", then the routine proceeds 
to step 3504 to display the contents of the "CF-Pollable" and "CF Poll Request" bit fields 
4608 and 4610 respectively according to the bit values as shown in Table 6 (see below). The 
routine then proceeds to step 3505 either from step 3503, or from step 3504, to display the 
contents of the remaining bits. If the "Privacy" bit field 4612 is set to one, the station is using 
WEP encryption. If the "Short Preamble" bit field 4614 is set to one the station is capable of 
running short preambles. If the Packet Binary Convolutional Coding (PBGC) is implemented, 
the "PBCC" bit field 4616 is set to one. It is set to zero otherwise. If the channel agility is in 
use the "Channel Agility" bit field 4618 is set to one. It is set to zero otherwise. The routine 
next displays the contents of the bits B8 - B15 as reserved at step 3506. The routine terminates 
at step 3507. A typical output of the DisplayCapa-bihtylnfonnatioiiElementO routine is shown 
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in Figure 58. 
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Table 5, Station usage of CF-Pollable and CF-Poll Request 
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Table 6. Access Point usage of CF-Pollable and CF-Poll Request 



With respect to Figure 36, the program executes the DisplaySSIDInfoxmationElemeaitO 
routine as denoted by the steps 3600 to 3608. The role of this routine is to format and to 
display the Service Set Identification (SSID) information field 4628. The structure of the SSID 
information element is shown in Figure 46C. Upon activation at step 3600, the routine 
proceeds to step 3601 to display the information element identification number. The 
information element ID for the SSID is equal to 0. The routine then proceeds to step 3602 to 
display the length of the SSID field 4628, The valid length of the SSID field 4628 is 0 - 32 
octets. The routine then proceeds to step 3603 to determine if the length is greater than 32 
octets. If **Y es", then the routine proceeds to step 

3604 to display a warning message "(should be <= 32)" indicating that the length of the SSID 
field should not be greater than 32 octets. The routine next proceeds to step 3605, either from 
step 3604 or step 3603, to determine if the length is set to zero octets. If "Yes", then the 
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routine displays via step 3605 a message "Broadcast Service Set Identity". The routine then 
proceeds to step 3607 to display the contents of the SSID field 4628. The routine terminates at 
step 3608, A typical output of the DisplaySSIDIiiformationElementO routine is shown in 
Figure 58. 

With respect to Figure 37, the program executes the 
DisplaySupportedRatesLiformationElementO routine as denoted by the steps 3700 to 3708. 
The role of this routine is to format and to display the "Supported Rates" information field 
4706. The structure of the Supported Rates information element is shown in Figure 47A. Upon 
activation at step 3700, the routine proceeds to step 3701 to display the information element 
identification number. The information element ID for the Supported Rates is equal to 1 . The 
routine then proceeds to step 3702 to display the length of the Supported Rates field 4706. The 
valid length of the Supported Rates field 4706 is 1 - 8 octets. The routine then proceeds to step 
3703 to determine if the length is greater than 8 octets or less than 1 octet If "Yes", then the 
routine proceeds to step 3704 to display a warning message" (should be 1 to 8 octets)" 
indicating that the length of the Supported Rates field 4706 should be between 1 to 8 octets. 
The routine next proceeds to step 3705, either from step 3704 or step 3703 (if "No"), to- 
determine if the length is greater than 0 octets, because each supported rate occupies 1 octet. If 
"Yes", then the routine proceeds to step 3706 to display the supported rate. If the most 
significant bit of each supported rate is set to one, the supported rate belongs to the Basic 
Service Set Basic Rate, The remaining bits describe the supported rate in units of 500 kbit/s. 
The routine next proceeds to step 3707 where the "Length" variable is decremented by 1 . The 
routine returns to step 3705 to determine if there is any more rates to display. If there is not 
any more rates at step 3705, the routine terminates at step 3708. A typical output of the 
MsplaySupportedRatesInfoimationElementO routine is shown in Figure 58. 

With respect to Figure 38, the program executes the 
DisplayUnknownlnformationElementO routine as denoted by the steps 3800 to 3804. The role 

57 



• WO 03/025597 



PCT/US02/29303 



of this routine is to format and to display the Unknown information field 4836. The structure 
of the Unknown information element is shown in Figure 48D. Upon activation at step 3800, 
the routine proceeds to step 3801 to display the information element identification number. 
The information element ID for the Unknown information element is specific to the 
manufacturer. Manufacturers use the reserved information element ID numbers to implement 
vendor specific information transfer. The routine then proceeds to step 3802 to display the 
length of the Unknown information field 4836. The routine then proceeds to step 3803 to 
display the contents of the Unknown information field 4836. The routine terminates at step 
3804. A typical output of the DisplayUnknownlnformationElementO routine is shown in 
Figure 71. 

With respect to Figure 39, the program executes the 
DisplayDSParameterSetlnformationElementO routine as denoted by the steps 3900 to 3906. 
The role of this routine is to format and to display the Direct Sequence (DS) Parameter Set 
information element 4716. The structure of the DS Parameter Set information element is 
shown in Figure 47B. The "Current Channel" field 4714 describes the channel being operated 
by the sending station. Upon activation at step 3900, the routine proceeds to step 3901 to 
display the information element identification number. The information element ID for the DS 
Parameter Set information element is equal to 3. The routine then proceeds to step 3902 to 
display the length of the "Cun-ent Channel" field 4714, which is 1 octet long. The routine then 
proceeds to step 3903 to determine if the length is equal to 1 octet. If "No", then the routine . 
proceeds to step 3904 to display a warning message "(should be 1 octet)" indicating that the 
length of the "Current Channel" field 4714 should be equal to one octet. The routine from 
either step 3903 if "Yes," or from step 3904, proceeds to step 3905 to display the contents of 
the "Current Channel" field 4714. The routine terminates at step 3906. A typical output of the 
DisplayDSParameterSetliifonnatioiiElementO routine is shown in Figure 71. 
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With respect to Figure 40, the program executes the 
DisplayCFParameterSetlnformatioiiElementO routine as denoted by the steps 4000 to 4006. 
The role of this routine is to format and to display Contention Free (CF) Parameter Set 
Information element 4730. The structure of the CF Parameter Set information element is 
shown in Figure 47C. Upon activation at step 4000, the routine proceeds to step 4001 to 
display the information element identification number. The information element ID for the CF 
Parameter Set information element is equal to 4. The routine then proceeds to step 4002 to 
display the length of the information field, which is 6 octets long. The routine then proceeds to 
step 4003 to determine if the length is equal to 6 octets. If "No", then the routine proceeds to 
step 4004 to display a warning message "(should be 6 octets)". The routine then proceeds to 
step 4005 from either step 4004, or from step 4003 if "Yes," to display the contents of the 
information field. The information field contains the CFP Count field 4722, CFP Period field 
4724, CFP Maximum Duration field 4726, and CFP duration remaining field 4728. The 
routine first displays the CFP Count field 4722. This field contains an unsigned number 1 octet 
long. The routine than displays the CFP Period field 4724 that is an unsigned number of 1 
octet length. The routine displays the CFP Maximum Duration field 4726, which is an 
unsigned integer that is 2 octets long. The routine then displays the CFP Duration Remaining 
field 4728. This field is an unsigned integer that is 2 octets long. The numbers described by the 
CFP Maximum Duration and CFPO Duration Remaining fields 4726 and 4728 respectively 
are expressed in terms, of time units. The routine terminates at step 4006. A typical output of 
the DisplayCETParameterSeiinformationElementO routine is shown in Figure 72. 

With respect to Figure 41, the program executes the 
DisplaylBSSParameterSetlrifonnatioiiElementO routine as denoted by the steps 4100 to 4106. 
The role of this routine is to format and to display the Independed Basic Service Set (IBSS) 
information element 4822. The structure of the IBSS information element is shown in Figure 
48B. The "Announcement Traffic Indication Message (ATTM) Window" field 4820 describes 
the ATIM window length in time units (TU). Upon activation at step 4100, the routine 
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proceeds to step 4101 to display the information element identification number. The 
information element ID for the IBSS information element is equal to 6. The routine then 
proceeds to step 4102 to display the length of the "A1TM Window" field 4820, which is 2 
octets long. The routine then proceeds to step 4103 to determine if the length is equal to 2 
octets. If "No", then the routine proceeds to step 4104 to display a warning message "(should 
be 2 octets)". The routine then proceeds to step 4105 either from step 4104, or from step 4103 
if "Yes," to display the contents of the "ATIM Window" field 4820. The routine terminates at 
step 4106. A typical output of the DisplaylBSSPaiameterSetlhformationElementO routine is 
shown in Figure 57. 

With respect to Figure 42, the program executes the 
DisplayTIMParameterSetlnfo^ routine as denoted by the steps 4200 to 4206. 

. The role of this routine is to format and to display the Traffic Indication Message (TIM) 
information element 4814. The structure of the TIM information element is shown in Figure 
48 A. Upon activation at step 4200, the routine proceeds to step 4201 to display the 
information element identification number. The information element ID for the TIM 
information element is equal to 5. The routine then proceeds to step 4202 to display the length 
of the information field, which is between 4 and 254 octets long. The routine then proceeds to 
step 4203 to determine if the length is less than 4 or greater than 254 octets. If "Yes", then the 
routine proceeds to step 4204 to display a warning message "(should be 4 to 254 octets)". The 
routine then proceeds from either step 4204, or from step 4203 if "No," from either step 4204, 
or from step 4203 if "No," to step 4205 to display the contents of the infonnation element. The 
information element contains the Delivery Traffic Indication Message (DTIM) Count field 
4806, DTIM Period field 4808, Bitmap Control field 4810, and Partial Virtual Bitmap field 
4812. The routine first displays the DTIM Count field 4806. This field is 1 octet long, and it 
contains an unsigned number. The routine next displays the DUM Period field 4808. The 
DTIM Period field 4808 is 1 octet long, and also contains an unsigned number. The Bitmap 
Control field 4810 is a single octet. The least significant bit (bit 0) of this field contains the 
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Traffic Indicator bit associated with Association ID 6. This bit is set to 1 whenever there is 
Multicast or Broadcast frames buffered at the Access Point. The remaining bits of the Bitmap 
Control field 4810 describes the bitmap offset of the Partial Virtual Bitmap field 4812. The 
routine then displays the contents of the Partial Virtual Bitmap field 4812. The routine 
terminates at step 4206. A typical output of the 

DisplayTIMParameterSetlnfonnati routine is shown in Figure 71. 

With respect to Figure 43, the program executes the 
DisplayChallengeTextlnformationElementO routine as denoted by the steps 4300 to 4306. The 
role of this routine is to format and to display "Challenge Text 5 * information element 4830. 
The structure of the "Challenge Text" information element is shown in Figure 48C. The 
"Challenge Text" field 4828 contains random information that is sent from the responding 
station to the requesting station in authentication frame exchange sequence. The requesting 
station then- encrypts the next authentication frame and sends it back. The responding station 
decrypts the contents of the authentication frame body and compares it with the random 
information it has sent. If they are the same then the requesting station is authenticated: Upon 
activation at step 4300, the routine proceeds to step 4301 to display the information element 
identification number. The information element ID for the Challenge Text information element 
is equal to 16. The routine then proceeds to step 4302 to display the length of the "Challenge 
Texf * field 4828, which is between 1 to 253 octets long. The routine then proceeds to step 
4303 to determine if the length is less than 1 octet or greater than 253 octets. If "Yes", then the 
routine proceeds to step 4304 to display a warning message "(should be 1-253 octets)". The 
routine then proceeds either from step 4304, or from step 4303 if "No," to step 4305 to display 
the contents of the "Challenge Texf' field 4828. The routine terminates at step 4306. A typical 
output of the DisplayChaUengeTexOnformationElementO routine is shown in Figure 73. Note 
that as previously mentioned, Figures 49 through 73 show display screens for various 
embodiments of the invention, respectively. 
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Although various embodiments of the invention have been shown and described, they 
are" not meant to be limiting. Those of skill in the art may recognize various modifications to 
these embodiments, which modifications are meant to be covered by the spirit and scope of the 
appended claims. 
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What Is Claimed is: 

1. A method for decoding information contained in an IEEE 802.1 1 header of data packets or 
frames transmitted between stations in a wireless Local Area Network (LAN), said method 
comprising the steps of: 

establishing a direct wireless logical connection with the wireless 
communications network; 

receiving wirelessly, in real-time, data packets or frames transmitted in the 
wireless communication network; 

storing in a memory storage device, the data packets or frames captured; and 
decoding and displaying the infonnation contained in the respective IEEE 
802. 1 1 headers of the data packets or frames stored in the capture buffer. 

2. The method of Claim 1, wherein said decoding and displaying step includes the steps of: 

displaying a menu to a user to permit the user to select a captured file containing 
frames and/or data packets; and 

analyzing in detail each bit of the IEEE 802.1 1 header of each frame of the captured 
file in the order they are stored in a capture buffer memory. 

3. The method of Claim 2, wherein said analyzing step further includes for analyzing a frame 
and/or data packet the steps of: 

determining the parameters necessary to decode the associated IEEE 802. 1 1 header of 
a current frame being analyzed; 

determining if the current frame is a portion of a larger fragmented frame; 
reassembling the current frame if it is determined it is a portion of a larger fragmented 

frame; 

determining the source and destination addresses of the current frame; 
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displaying the source and destination addresses of the current frame; 
executing a summary routine for determining short concise summary information 
relative to a current frame; 

displaying said summary information about the contents of the current frame; 
decoding individually for each layer the information contained in the current frame; 
and 

displaying the decoded information. 

4. The method of Claim 3, wherein said decoding step further includes the steps of: 

determining the parameters required to decode the information in the current frame; 
determining the frame type and subtype of the current frame; 
storing in memory the frame type, and subtype of the current frame; and 
displaying the frame type and subtype. 

5. The method of Claim 4, wherein said step of determining the frame type and subtype of the 
current frame, further includes the steps of: 

detennining if the current frame is a "Management frame"; 

determining, if not a management frame, if the current frame is a "Control" frame; 

determining, if not a Control frame, if the current frame subtype is either an 
"Acknowledgment (ACK)" or "Clear to Send (CTS)" frame; 

detennining, if not an ACK or CTS frame, if the current frame is a "Data" frame; 

detennining, when the frame is a "Data" frame, if both the ToDS and FromDS fields 
are set to one; and 

setting the value of a variable "ulHeader Length" to a value indicative of the 
determined frame type and subtype of the current frame. 
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6. The method of Claim 3, wherein said steps of reassembling the current frame, further 
includes for determining the parameters required to reassemble a fragmented frame, the steps 
of: 

determining whether the current frame is one of a "Control" frame or a frame with an 
error, or an encrypted frame, and if "Yes", disable its reassembly; 

dete rminin g, if "No" in the previous step, if the current frame is originally decrypted, 
and if so increase its length by 4 octets, but if not, set the data offset to the length of the MAC 
header, and the current frame's length to ulFragmentLength; 

detennining if "More Flag" field of the current frame is set to one, said step further 
including if "Yes" detennining if the fragment of the current frame is zero, and if "Yes," set 
the fragment type to "First Fragment", set the data effort to zero, and enable reassembly, 
whereas if the fragment is not zero, set the fragment type to "Middle Fragment", reduce the 
fragment length of the current frame by the data offset, and enable reassembly; 

determining, in response to the "More Flag" being set to zero, if the fragment number 
is zero, said step further including if <e Yes" disabling reassembly of the current frame, whereas 
if "No," set the fragment type to "Last Fragment," reduce the fragment length by the data 
offset, and enable reassembly; and 

determining if the current frame is a decrypted frame, if 'Yes," increase the fragment 
length by 4 octets. 

7. The method of Claim 3, wherein said step of determining the source and destination 
addresses of the current frame includes the steps of: 

determining if the current frame type is a "Control" frame; 

detennining, if 'Yes" in the immediately previous step, if the current frame subtype is 
either an "Acknowledgment (ACK)" or "Clear To Send (CTS)" frame, and if "Yes" set a 
variable "DestAddr" to the contents of an "Addressl" field, followed by determining if the 
transmitter address is known, if so, set the contents of an "Implied Transmitter Address" 

65 



' WO 03/Q25597 



PCT/US02/29303 



variable to the address of the transmitting station; 

determining, in response to the current frame type not being a "Control" frame, if the 
frame type is a "Management" frame, and if ' Yes," set "DstAddr" and "SrcAddr" variables to 
the contents of "Address 1" and "Address2" fields, respectively; 

determining, in response to the current frame type not being a "Management" frame, 
whether the current frame type is a "Data" frame; and 

determining, in response to the current frame being a "Data" frame, if a "ToDS" bit 
field is set to zero, and if "Yes," set a "DestAddr" variable to the contents of an "Address 1" 
field, followed by the steps of determining if a "FromDS" bit field is set to zero, and if "Yes", 
set a variable "SrcAddr" to the contents of an "Address2" field, whereas if "No", set the 
variable "SrcAddr" to the contents of an "Address3", whereas if the 'ToDS: bit field is not set 
to zero, set the variable "DstAddr" to thexontents of the "Address3" field 36, followed by 
determining if "ToDS" bit field is now set to zero, and if * Yes", set the variable "SrcAddr" to 
the contents of the "Address2 M field, whereas if the 'ToDS" bit field is not set to zero, set the 
variable "SrcAddr" to the contents of an "Address4" field. 

8. The method of Claim 4, wherein said summary routine includes the steps of: 
initializing a string to be used in a summary line for display; 

formatting the data rate and signal strength level provided by a Network Interface Card 

(NIC); 

using a bit value indicative of the subtype of the current frame, as obtained from said 
step for detennining the subtype, to format the name of the frame subtype from a table 
established to correlate the bit values to frame subtype names, respectively; 

detennining if a wired equivalent privacy (WEP) bit field is set to one, and if <c Yes," 
add a WEP string to said summary line; and 

determining if a "Retry" bit field is set to one, and if <c Yes," add a "Retry" string to said 
summary line. 
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9. The method of Claim 4, wherein said step of decoding further includes the step of: 

determining if the frame type is a "Management Frame"; 

executing a FormatManagementDetailO subroutine in response to determining a 
"Management" frame; 

determining if the frame type is a "Control" frame, in response to it not being a 
'Management" frame; 

executing a FormatControlDetailO subroutine, in response to the frame being a 
"Control" frame; 

detennining, in response to the frame not being a "Control" frame, if it is a <c Data" 
frame; and 

executing a FormatControlDetailO subroutine in response to the frame being a "Data" 

frame. 

10. The method of Claim 9, wherein said FormatManagementDetailO subroutine includes the 
steps of: 

deter minin g via a Network Interface Card (NIC) physical layer related information; 
executing a DisplayPhysicalLayerlnformationO routine to display said physical layer 
related information; 

executing a DisplayFrameControIFieldO routine; 

displaying the contents of a duration field as a little-endian unsigned integer of two 
octets in lengths; 

executing a DisplayDestinationAddressO routine to display a destination address; 
executing a DisplaySourceAddressO routine to display a source address; 
executing a DisplayBSSIDO routine to display Basic Service Set Identification 
information; 

executing a DisplaySequenceControlFieldO routine to display fragment and sequence 
numbers for the current frame; and 

executing a FonnatManagementFrameSubtypeO to a decode and display information 
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contained in a frame body section specific to management frame subtypes. 

11. The method of Claim 10, wherein said FormatManagementFrameSubtypeO includes the 
steps of: 

determining if the frame subtype is an "Association Request 5 * frame; 

executing, in response to the frame being an "Association Request, a 
DisplayAssociationRequestFrameDetailO, for displaying the frame details; 

determining, in response to "No" for the immediately precoding determining step, if 
the frame subtype is aReassociation Request" frame; 

if "Yes", execute a DisplayReassociationRequestFrameDetailO routine; 
if 'No", determine if the frame subtype is either an "Association Response" or 
"Reassociation Response" frame; 

if "Yes", execute a DisplayRe_associationResponseFrameDetailO; ' 
if "No", determine if the frame subtype is a "Probe Requesf * frame; 
if "Yes", execute a DisplayProbeRequestFrameDetailO routine; 
if "No", determine if the frame subtype is a "Probe Response" frame; 
if "Yes", execute a DisplayProbeResponseFrameDetailO routine; 
if the frame subtype is not a "Probe Response," determine if the frame subtype is a 
"Beacon" frame; 

if "Yes", execute a DisplayBeaconFrameDetailO routine; 

if "No", determine if the frame subtype is a "Disassociation" frame; 

if "Yes", execute a DisplayDisassociationFrameDetailO routine; 

if "No", determine if the frame subtype is an "Authentication" frame; 

if "Yes", execute a DisplayAuthenticationFrameDetailO routine; 

if TSTo" determine if the frame type is a "Deauthentication" frame; and 

if "Yes", execute a DisplayDeauthenticationFrameDetailO routine. 

12. The method of Claim 1 1, wherein said DisplayAssociatzonRequestFrameDetailO routine 
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includes the steps of: 

display the contents of a 'listen Interval*' field 4408, to indicate to a current Access 
Point how often a station wakes to listen to Beacon management frames; 
display a MAC address of the current Access Point; 

display a current AP address field 4508 by executing a DisplaySourceAddressO 
routine; 

execute a DisplaySSIDInfonnationElementO routine; 

execute a DisplaySupportedRatesInfonnatioiiElementO routine; 

determine if there is an unknown information element at the end of the frame; and 

if tfi Yes", execute a IMsplayUnknownlnformationElementO routine. 

13. The method of Claim 14, wherein said DisplayRe_associationResponseFrameDetailO 
routine includes the steps of: 

execute a DisplayCapabilitylnfonnationElementO routine; 

display the contents of a "Status Code" field 4506 obtained from a table of code 

values; 

display the contents of an "Association ID" field 4504 as an unsigned integer, 

set the two most significant bits of an association ID field 4504 to ones; 

execute a DisplaySupportedRatesIhfonnationElementO routine; 

determine if there is an unknown information element at the end of the current frame; 

and 

if ''Yes", execute a DisplayUnknownlnformationElementO routine. 

14. The method of Claim 11, wherein said DisplayProbeRequestFrameDetailO routine 
includes the steps of: 

execute a DisplaySSIDInfonnationElementO routine; 

execute a DisplaySupportedRatesInformationElementO routine; 

determine if there is an unknown information element at the end of the current frame; 
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and 

if "Yes", execute a DisplayUnknownlnfonnationElementO routine. 

15. The method of Claim 11, wherein said DisplayProbeResponseFrameDetailO routine 
includes the steps of: 

display a 'Time stamp field 4602 as an unsigned little endian integer; 

display a <r Beacon Interval" field 4406 representing the number of time units between 
target beacon transmission times; 

execute a DisplayCapabilitylnformationElementO routine; 

execute a DisplaySSIDInformationElementO routine; 

execute a DisplaySupportedRatesInformationElementO routine; 

execute a DisplayDSParameterSetlnfonnationElementO routine; 

determine if the frame contains a "CF Parameter Set 5 9 information element as 
transmitted by Access Points supporting a Point Coordination Function, 

and if so execute a DisplayCFParameterSetlnfonnationElementO routine; 

determine if the sending station is operating in an Independent Basic Service Set, and if 
so execute a DisplaylB SSParameterSetlnfonnationElementO routine; 

determine if there is an unknown information element at the end of the frame; and 

if "Yes", execute a DisplayUnknownEoformationElementO routine. 

16. The method of Claim 11, wherein said DisplayBeaconFrameDetailO routine includes the 
steps: 

display a 'Timestamp" field 4602; 

display a "Beacon Interval" field 4406 representing the number of time units between 
target beacon transmission times; 

executing a DisplayCapabihtylnfoimationElementO routine; 

execute a DisplaySSIDInformationElementO routine; 

execute a DisplaySupportedRatesInfonnationElementO routine; 
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execute a DisplayDSParameterSetlnfonnatioiiElementO routine; . 

detennine if the frame contains a "CF Parameter Sef ' information element as 
transmitted by Access Points supporting a Point Coordination Function, and if so, execute a 
DisplayCFParameterSetlnfoTmationElementO routine; 

determine if an associated sending station is operating in an Independent Basic Service 
Set, and if so, execute a DisplaylBSSParameterSetlnformationElementO routine; 

execute a DisplayTIMP arameterSetlnformationElementO routine; 

determine if there is an unknown information element at the end of the frame, and if 
•"Yes", execute a DisplayUnlmownlnformatiorLElementO routine. 

17. The method of Claim 11, wherein said DisplayDisassociationFrameDetailO includes the 
steps: 

display the contents of a 'Heason Code" field 4502; 
display a message corresponding to a "Reason Code" field 4502; and 
determine if there is an unknown information element at the end of the frame, and if 
"Yes," execute a DispIayUnknownlnformationElementO. 

18. The method of Claim 11, wherein said DisplayAuthenticationFrameDetailO routine 
includes the steps of: 

determine if a "WEP" bit field is set to one, and if "Yes", the frame is originally 
encrypted; 

display, if "Yes," the contents of a WEP-IV field; 

detennine if the frame is decrypted, and if "No," display the contents of the encrypted 

data; 

display the contents of a WEP-ICV field that carries an 'Integrity Check Value" of 
encrypted data; 

if the frame is not originally encrypted or the frame is decrypted, display the contents 
of an "Authentication Algorithm Number" field that is an unsigned number for which allowed 
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values are 0, which corresponds to Open System Authentication, and 1, which corresponds to 
Shared Key Authentication; 

display the contents of an "Authentication Transaction Sequence Number" field that is 
an unsigned number used to identify the frame number used in an authentication exchange 
sequence; 

display the contents of a "Status Code" field 4506; 

determine whether the "Authentication Algorithm Number" is equal to 1 (Shared Key), 
and the transaction sequence number is either 2 or 3, and if ce Yes" execute a 
DisplayChallangeTextlnformationElementO routine; 

determine if there is an unknown information element at the end of the frame, and if 
'Tes" execute a DisplayUnknownlnfonnationElementO routine; and 

determine if the frame is a decrypted frame, and if "Yes", display the contents of a 
WEP-ICV field, 

19. The method of Claim 1 1, wherein said DisplayAuthorizatioonFrameDetailO routine is for 
decoding and displaying information contained in a frame body field of a "Deauthentication" 
management frame subtype, includes the steps: 

display the contents of a <c Reason Code" field 4502 that is an unsigned number; 
display a message corresponding to the "Reason Code" field 4502; and 
determine if there is an unknown information element at the end of the frame, and if 
'Tes," execute a DispiayUnknownlnfoimationElementO routine. 

20. The method of Claim 9, wherein said FormatCTRLDetailO routine for decoding and 
displaying information contained in a "Control" frame type includes the steps: 

execute a DisplayPhysicalLayerlnfonnationO routine to display the physical layer 
related information determined by a Network Interface Card (NIC); 
execute a DisplayFrameControlFieldO routine; 

determine if the frame subtype is a 'Tower Save (PS) - Poll" frame, and if "Yes" 
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execute a FonnatPS JPOLLDetailO routine; 

determine, if "No" in the immediately previous step, whether the frame subtype is a 
"Request To Send" (RTS) frame, 

execute a FormatRTSDetailO, if "Yes" in the immediately previous step; 

if the result of the immediately previous "determine" step is "No" determine if the 
frame subtype is not RTS, whether the frame subtype is either a "Clear To Send (CTS)" or an 
"Acknowledgment (ACK) frame, and if cc Yes", execute a FormatCTS_ACKDetailO; and 

if the frame subtype is not CTS or ACK, determine whether the frame subtype is either 
a "Contention Free (CF) - End" or a "CF - End + CF-Ack" frame, and if "Yes", execute a 
FonnatCF__END_ACKDetailO routine. 

2 1 . The method of Claim 20, wherein said FomatPS JPOLLDetailO routine for decoding and 
displaying information container in said Power Save (PS) - Poll frame, includes the steps: 

determine if the two most significant bits of an "Association ID" field are not set to 
one, because the IEEE 802. 1 1 standard requires these bits to be set to one, and if "Yes", 
display a warning message "2 MSB bits of Association ID field should be 1"; 

if "No" for the previous step, check if the little endian number in the "Association ID" 
field is between 1 and 2007, and if "Yes", display the contents of the "Association ID field" as 
an unsigned integer, 

if the result of the immediately previous step is "No", display a warning message 
"Association ID should be in range 1 to 2007"; 
execute a DisplayBSSIDO routine; and 
execute a DisplayTransmitterAddressO routine. 

22. The method of Claim 20, wherein said FormatRTSDetailO routine for decoding and 
displaying information contained in said RTS frame, includes the steps: 

display the contents of a duration field as a little-endian unsigned integer; 
execute a DisplayReceiverAddressO routine; and 
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execute a DisplayTransmitterAddressO routine. 

23. The method of Claim 20, wherein said FormatCTS_ACKDetailO routine for decoding and 
displaying information contained in said CTS and ACK frames, includes the steps: 

display the contents of a duration field as a little-endian unsigned integer; 
execute a DisplayReceiverAddressO routine; 
determine if the transmitter address is known; and 

if the transmitter address is known, execute a DisplayTransmitterAddressO routine. 

24. Network analysis apparatus for wirelessly monitoring data frames transmitted between 
stations in a wireless communication network, said apparatus comprising: . 

a wireless network interface device working in a promiscuous mode within a wireless 
communications network, for capturing a plurality of frames and/or data packets transmitted 
through the network; 

a user interface system comprising input devices, and output devices, including a 
display, for enabling a user to input and obtain information associated with said plurality of 
captured frames and/or data packets; 

a memory storage device for storing the plurality of captured frames and/or data 
packets from the wireless communications network; 

a central processing unit (CPU) connected to said wireless network interface device, 
said user interface system, and said memory storage device; and 

means for program m ing said CPU to operate said wireless network interface device, 
user interface system, and memory storage device, for decoding selected ones of said plurality 
of captured frames and/or data packets, and displaying the information contained in the 
respective IEEE 802.1 1 headers thereof. 

25. The apparatus of Claim 24, wherein said means for programming said CPU, includes the 
steps of: 
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establishing a direct wireless logical connection with the wireless communications 
network via the network interface device; 

receiving wirelessly, in real-time, frames and/or data packets transmitted in the 
wireless communications network via direct wireless logical connection; 

receiving one or more frame and/or data packet attribite parameters inputted by a user 
through the user interface system; 

storing in the memory storage device, the frames and/or data packets received from the 
wireless networic via direct wireless logical connection; and 

decoding in detail and displaying to the user, the information contained in the frames 
and/or data packets stored in the memory storage device. 
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DisplayCapabilitylnl 


r 

01 

ormatlonEtementO; 


_ i 




1102 

D Is pla yUs le n In terva II n fo rm atlo n E le m e n t() ; 






1103 

OisplaySSIDInformationEJementQ; 




YES-> 



1106 

D is playUn known lnformationElementQ; 



Figure 1 1 
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1004 

DlsplayReassoctatlonRequestFrameDetailO 




1201 

DisptayCapabintylnformationElementO; 



12 

D Isplay Lis ten Intervall 


l 

02 

nform ationE lem ent(); 




r 



1203 

DIspJayCurrentAPAddresstO; 




Figure 12 
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1301 

DIsplayCapabllitylnformatlonElementO; 



± 

1302 

Displays tatusCode(); 



1303 

DlsplayAs sociatlon ID Information ElementO; 



1304 

DisplaySupportedRateslnformatlonElement(); 




Figure 13 
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1401 

DlsplaySSlDlnformattonE!ernent(); 



± 

1402 

DisplaySupportedRates)nformationElement(); 




1404 

DlsplayUnknown Inform ationElement(); 



Figure 14 
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1010 

DIsplayProbeResponsaFrameDetaHO 




1501 

D Is p lay T(m esta m p (}; 



1502 

D Is p lay B e a con I n terva I ( ); 



1503 

D is play Capability I nformatlonElement(); 



1504 
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1505 

DlspIaySupportedRateslnformatlonEIement(); 



1506 

DIsplayDSParameterSetlnformatlonElementO; 



1507 

DlsplayCFParameterSetlnformatlonElament(); 



1508 

Display iBSSParameterSetlnformationElementO; 




YE5- 



1510 

DlsplayUnknownlnformatlonElamenU); 



Figure 15 
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DIsplayTIm estam p(); 

I 

1602 

D isplayBeaconlntervalO; 

I 

1603 

DlsplayCapabllltylnfarmatlonElement(); 
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D Is p layS SID In formation ElementO; 



± 

1605 

D is playS u p portedR ates Inform atlonElem ent(); 



1606 

DfsplayDSParameterSetlnformatlonElementO; . 
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1607 
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1608 
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1014 

DisplayDtsassoclationFrameDetail() 
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DispiayReasonCode(); 




1703 

DIsplayUnknownlnformatlonElementO; 



Figure 17 
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DisplayStatusCodeO; 
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1018 

DIsplayDeauthen tica tion Frame Data 





t 


1901 

DIsplayReasonCodeO; 



1903 

Display Unknown Inform a tion Element(); 



NO 
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NO 

_4_ 



2105 

DisplayW arnfng(); 



2106 

DIsplsyBSSID(); 



2107 

DlsplayJransm Ute rAd dress (); 




Figure 21 



WO 03/025597 



PCT/US02/29303 



2 2/7 3 




2201 

D jspiayO u ration Fie Id (); 



22 

D IsplayRecel 
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2 4 0 1 

O is p la y D uratlon Field (); 



2 4 0 2 

O Is p la y R eceiverA d d re s s (); 



2 4 0 3 

D is p la y B S S ID (); 



C 2 4 0 4 ^ 



Figure 2 4 



WO 03/025597 



PCT/US02/29303 



25/73 




2501 


— * 


2502 


— > 


2503 


DteplayPhysIcalLsyertnfonTtattonO; 




DteplayFrameCantrolHetdO; 




DisptayDuratJonRetdO; 




-NO- 



2504 
ToOS « 0? 



NO 
2512 



YES* 



2505 

DlsplayDestJnationAddressO: 



2517 

Display Receiver Address (); 





2506 



2518 

EXsplsyTransntfterAddressfr 
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2513 

DlspiayBSSlDQ: 



NO 

JL 



2509 



2507 

DtepIaySourtseAddressO; 



2519 

OsplayOastfnaUonAddressO; 



2520 

DfspiaySequsnoeConlrolHddft 



2514 

KsplayScxirceAdcfressO; 

I 



2510 



2521 

DteptaySourceAddressQ; 



2515 

DfcpfayOeslinaUcnAddressO: 

I 



2508 



2511 

DIspIaySequenceCanirotReldO; 



2516 

Display SequenceControlFteidO; 



2524 

OIsplayWEPJVO; 




OtepteyWEPJCVQ; 
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2700 

DisplayPhyslcalLayerlnformatlonO 




2701 

Q lap lay F ramoTIm oA ndF ram e Size (); 




2703 

Displays UcedFram eSlze(); 



2705 
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NO 

J2 



2706 

D lap lays IgnalteveU): 

i 

2707 

DtsplayChannelNurobOTOV 

I 

2708 

OlsplayO ataRateO; 



2709 

bShortPLCPHoador as 
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2710 
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YES- 
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O tap lay E n cry p lion Info (); 
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D IsplayFram e C o n tro IF te Id () 
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D Is p la y V e rs I 
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O Is p la y R e try In fo (); 
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D Isplay W E P In fo (); 

DlsplayO rderlnfo(); 
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2902 

DlsplayStrtng(*BROAOCAST'); 



NO 
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Disp!ayString("Multicast"); 



NO 



2905 

D Is play S trln g ("Station"); 
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DisplayEEEMACAddressO; 
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DisplayString("Stat!on n ); 
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3002 

DisplayEEEMACAddress(); 
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3202 

DisplayStrlng(-8RO ADC AST'); 



NO 



3204 

Dlsp1ayString(»M ulticast"); 



NO 

± 

3205 

D Is playString ("Station"); 
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Display EE EM AC Address(); 
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Display String ('Station*); 
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DlsplayEEEM ACAddress(); 
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3400 

Is play 8 oq us n co C ontro IF la Id () 



340 1 

SeqNum ■ 3 o q C o n tro IP ie Id & OxFFFO >> 4: 
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DlsplaySeqNum {); 
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C3405 ^ 



Figure 3 4 



WO 03/025597 



PCT/US02/29303 



35/73 



3500 

Display Capability Inform atlonElam ent{) 




± 

3501 

DIsplayESSBltO; 
DisplaylBSSBitO; 
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DIsplayCFPollBitsForR e_AsscoReqFram es(); 
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± 
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OlspfayCFPoUBftsForOtherFramesO; 
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DlsplayPrlvalcyBUO; 
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DlsplayPBCCBltO; 
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D!splayReservedFleld(); 




Figure 35 



WO 03/025597 



PCT/US02/29303 




F ig u re 3 6 



WO 03/025597 



PCT/US02/29303 



37/73 




1 

3701 

D IsplayE lem entID (); 



3702 

0 (splayLen gth (); 
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D Isptay W arning(); 
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Length » Length - 1; 
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3900 

D IsplayD S P a ram e te rS e tin fo rm a Ho n E le m en t() 



3901 

DlsplayElem entlO {); 



3902 

D isplay Length (); 



3904 

D fspla y W a rning (); 
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D IsplayC FParam e te rS e tin fo rm a tio nElem ent() 
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DIsplayElem e ntlD (); 
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D IsplayLength(); 



4103 

Length = = 2 ? 
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D IsplayW a rning(); 



4105 

D isplayATIM W Indow; 
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END 
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D isp la y E le m en tID (); 



4202 

D isp layLen gth (); 




4204 

D isplayW a rn in g (); 
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4402 



BO 



L 



B15 



Authentication Algorithm Number 



Octets: 2 

Figure 44A (Authentication Algorithm Number Fixed Field) 



4404 



BO 



L 



B15 



Authentication Transaction 
Sequence Number 



Octets: 2 

Figure 44B (Authentication Transaction Sequence Number Fixed Field) 
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B0 



L 



B15 



Beacon Interval 



Octets: 2 

Figure 44C (Beacon Interval Fixed Field) 
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BO 



B15 



Usten Interval 



Octets: 2 

Figure 44D (Listen Interval Fixed Field) 
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4502 



BO 



L 



B15 



Reason Code 



Octets: 2 

Figure 45A (Reason Code Fixed Field) 
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B15 



Association ID (AID) 



Octets: 2 

Figure 45B (Association ID Fixed Field) 
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B0 / B15 



Status Code 



Octets: 2 

Figure 45C (Status Code Fixed Field) 
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i 1 \— r 

Current AP Address 



~* 

Octets: 6 

Figure 45D (Current AP Address Fixed Field) 
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4602 



BO 



cms 



Timesfcannp 



Rgure 46A (Timestarrp Rxed Reld) 



4622 



4604 4606 4608 4610 4612 4614 4616 4618 4620 



BO 



B15 



ESS 


IBSS 


CF 
Roilabe! 


CFPtfl 
Request 


Rivacy 


Rearrfale 


PBGC 


Channel 


Rsserved 


M 
















► 



Cdels 



Rgure 46B (Capability Infomnation Rxed Reld) 



4630 



4624 



4625 



4628 



/ / 



L 



BenreitlD 


Length 


S3D 




1 


1 


1-8 





oasis 



Rgure 46C (SSID Information Bement Format) 
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4708 



4702 



4704 



4706 



L L 



L 




Bemerrt ID 


Length 


Supported Rates 










► 

1 


^ 

1 


0-32 


► 



Octets: 



Figure 47A (Supported Rates Information Element Format) 



4710 



1 




Element ID 


Length 


Current 
Channel 


► 



Octets: 1 1 1 

Figure 47B (DS Parameter Set Information Element Format) 
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4718 4720 4722 4724 4726 4728 




Element 
ID 


Length 


CFP 
Count 


CFP 
Period 


CFP MaxDuratfon 
(TU) 


CFP DurRemainfng 
(TU) 




1 


1 


1 


1 


2 2 



Figure 47C (CF Parameter Set Information Element Format ) 
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4814 



Element 


Length 


DTIM 


DTIM 


Bitmap 


ID 


Count 


Period 


Control 



4812 



Partial Virtual Bitmap 



M 

Octets: 11111 1-251 

Figure 48A (TIM Information Element Format) 
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4816 4818 

/ / 



4820 



L 



Bement ID 


Length 


AT1M Window 


► 


M 




► 



Octets: 11 2 

Figure 48B (IBSS Information Element Format) 
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L L 
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L 



Element ID 


Length 


Challenge Text 


^ ► 



Octets 1 1 1-253 

Figure 48C (Challenge Text Information Element Format) 
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4832 4834 

L L 
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L 
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Length 


Unknown Information 


Octets: 


M fr» 

1 1 





1-255 


► 



Figure 48D (Unknwon Information Element Format) 
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CaptumRes 

■^^^s^+^rvrrH.-vW*! 



g Sazar_fafledtodecode.cap 
»j Elazar_failedtDdecodB_slnglebeacon. cap 
3 teap_packet.cap 
3 LongDataandACXframas.cap 
5 newmethod4fragments , cap 
3 rBtryfbrleap .cap 
3 sarnplo_jATM . cap 
| sampleE theme t. cap 
| sampleTring.cap 



;;-j]sinq!eassoci3tionresponse.cap 



singleauthentteatton.cap 
i singfebeacon . cap 
| sfngteCF JEPdframe. cap 

| singteCRCRame.cap 

»Jslngiedata.cap 
»} singtedeauthentication.cap 
3 singledlsassodatton.cap 
3 singleeapol.cap 

^ stngleencryptedauthenticatlonframe . cap 
singleencryptedauthentkzatlonframeconv .cap 
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Airont2AlA39 
Airont3080F2 
Airont3080F2 
Airont2AlA39 
Airtmt2AlA39 
Aixont3Q80F2 

Airont3080F2 
Airant2AlA39 
Airant308QF2 
Airant2AlA39 



|Airont3Q8QF2 
Airont2AlA39 
Airant2AlA39 
Airont3080F2 
Aircnt3080F2 
Aircnt2AlA39 
Airant30B0F2 
Airont2AlA39 
Airont3Q60F2 
Aircnt2AlA39 
Airont3080F2 



GQ2.11: 
802.11: 
802.11: 
802.11: 
802.11: 
802.11: 
B02.ll: 
802.11: 
802.11: 
802.11: 
802.11: 



Signal-lOGJi, 
Signal- Q1H. 
Signal»100*, 
Signal-lQOfc, 
Signal- 100?:, 
Signal- 87*. 
2.0 Hbps. Signal- 81*. 
2.0 Hbps, Signal-100*. 
11.0 Hbps, SignaWOOJj, 
2.0 Hbps. Signal -100*. 

_ ~ " ~ zi ".jlw 



1.0 1 

2.0 : 

2.0 i 
1.0 Hbps, 
1.0 Hbps. 

2.0 r 



Lticatinn 
Acknowledgment (ACK) 
Authentication 
Acknowledgment (ACK) 
Association request 
Acknowledgment (ACK) 
Acknowledgment (ACK) 
Authentication. Ratry 
Acknowledgment (ACK) 
Association response 
Acknowledgment (ACK) 



Frame 179 arrived at I 
Signal level 
Channel 
Data rate 

Frame Control Field tl 

00 

.... 10.. 
0000 .... 

Frame Control Field tl 

0 

1. 



: 37: 30. 2556; frame size is 62 (003E best) byte 

- 100* 

- 1 

- 4 ( 2.0 Megabits per second) 

08 

0x0 Protocol Version 
0x2 Data Frame 
0x0 Data (Subtype) 
02 

Hat to Distribution System 
From Distribution System 
last fragment 
Hot retry 
Active Mode 



OO0Q0O0O: ill 

00000010: C^8Lg^Q^0il^3MPiHa 42 
00000020: 80 00 00 10 7b £4 da 04 00 
00000030: 27 03 00 £4 80 10 00 6b 14 




mti&wam 

42 03 00 00 00 00 00 I 

00 00 64 80 00 00 40 I . . .{ofi. . . .dl . .« 
00 02 00 Of 00 \.6|..k 



0:iO 
0:fg 
0:C* 

0 
0 

:;8 

or 



I 
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-QDLC: 
DLC: 



Capability information field #1 

1 

.. ..0. 
.. 00.. 
.0 .... 

1 

.0 

0 

Capability information fiBld #2 
1000 0000 

listen interval ° 

Element ID 
. . .length 

. . .Service Set Identity 



tended Service Set is on 
Independent Basic Service Set is off 
= STA is not Contention Free-Pol lable ] 
Ho privacy j 
Short Preamble option is implemented 
Packet Binary Convolutional Coding Modulation I 
Channel agility is not in use 
80 I 



200 

0 (Service Set Identifier) 
3 cctet(s) 



Element ID 
. . .length 

. . .Supported Hates 



. . .Supported Rates 
. . .Supported Rates 
. . .Supported Rates 



■ 1 (Supported Rates) 
= 4 octet (s) 
information field - 02 

0 

.000 0010 
information field = 

0 

.000 0100 
information field 

0 

.000 1011 
information field 

0 

.001 0110 



Not Basic Service Set Basic Sate 

1.0 Megabits per second 
04 

Hot Basic Service Set Basic Rate 
2.0 Megabits per second 
OB 

Hot Basic Service Set Basic Sate 
5.5 Megabits per second 
16 

Hot Basic Service Set Basic Rate 
11 . 0 Megabits per second 




WW'- : 
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S Sniffer Wireless - Locals, 802.11 Wireless LAN (Line spBed at 11Mbps) PS Channel 6 - Signal lovelV 84 Mr ^OifMS^Pj 



mmm 



..0 
.0. 



Capability information field #2 
0000 0000 

listen interval ■ 
Current Access Point address ■ 

Element ID ■ 
. . .length 

. . .Service Set Identity 

Element ID ° 
. . .length 



■ Extended Service Set is on 

■ Independent Basic Service Set is off 
» STA is not Contention Free-Pol lable 

° Ho privacy 

- Short Preamble option is not implemented 

° Packet Binary (^involutional Coding Modulation 
* Channel agility is not in use 

- 00 

■ Reserved 
1 

Station SymbolS0B7DA 

0 (Service Set Identifier) 
4 octet (s) 



1 (Supported Rates) 
4 octet (s) 



I 

H 
m 
$ 

m 



.Supported Rates information field ■ 82 



.000 0010 - 

. . .Supported Rates information field - 

1 - 

.000 0100 » 

. . .Supported Rates information field ■ 

0 - 

.000 1011 » 

. . .Supported Rates information field ■ 

0 * 



Basic Service Set Basic Rate 

1.0 Megabits per second 
84 

Basic Service Sat Basic Rate 
2.0 Megabits per second 
0B 

Not Basic Service Set Basic Rate 

5.5 Megabits per s ec on d 
16 

Not Basic Service Set Basic Rate 



i 



.001 0110 ° 11.0 Megabits per second 



i 



00000000: 20 08 fO fO 00 aO fB 93 24 db HE^I^^MSL 
00000010: 00 aO f8 93 24 db 20 cS 01 00 01 00 00 aO f8 90 
00000020: b7 da 00 04 49 45 45 45 01 04 82 84 0b 16 



as. auirggiS 

al$0A.... 
.IEEE. .11 
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Sniffer Wireless - Local_2, 802.11 Wireless LAN (Line speed at 11 Mbps) DS Channel 6 L SighaliL'flveP^^^S^^® 




M [1] |Synbol8E021E llnt rslQlOUF 1 802 11: 1.0 Mbps, Signal " 100^, Association response 



Destination Address ■ 

SourcB Address c 

Basic Service Set ID 

Sequence Control 0 

. . .Sequence Number ■ 

. . .Fragment Number 

Capability information field #1 

1 

0. 

... 00 
..1 .. 
.0. 
.0.. .. 
0 

Capability information field #2 
0000 0000 

Status code ° 
Association ID - 

Element ID ■ 
. . .length 



.Supported Rates information field 3 82 



Station IntrslOlOUF 
Station Symbol8E021E 
Syabol8E021E 
0xSA20 

0x5A2 (1442) 
0x0 (0) 
« 11 

8 Est ended Service Set is on 
«* Independent Basic Service Set is off 
* No point coordinator at Access Point 

■ Privacy 

» Short Preamble option is not allowed 

- Packet Binary Convolutional Coding Modulation node 

* Channel agility is not in use 

« 00 

■ Reserved 

0 (Successful) 
1 

1 (Supported Rates) 
4 octet (s) 



.000 0010 

. . .Supported Rates information field 

1 

.000 0100 

. . .Supported Rates information field 

0 

.000 1011 

. . .Supported Rates information field 

0 

.001 0110 



Basic Service Set Basic Rate 

1.0 megabits per second 
84 

Basio Service Set Basic Rate 
2.0 Megabits per seco n d 
0B 

Not Basic Service Set Basic Rate 
5.5 Megabits per second 
16 

Not Basic Service Set Basic Rate 
11.0 Megabits per second 



11 00 00 00 01 cO 01 04 




Figure 55 
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...o 

..0. 
.0.. 
0.., 

Duration 

Destination Address 
Source flrtriress 
Basic Service Set ID 
Sequence Control 
. . .Sequ en ce Number 
, . .Fragment Humber 
Element ID 
. . .Length 

. . .Service Set Identity 

Element ID 
. . .length 



Hot to Distribution System 
Hot from Distribution System 
last fragment 
Hot retry 
Active Mode 
Ho more data 

Wired Equivalent Privacy is off 
Hot ordered 

0 (in microseconds) 
BROADCAST FFFFFFFFFFFF, i 
Station Airont2AlA39 
BROADCAST FFFFFFFFFFFF 
0x0210 
0x021 (33) 
0x0 (0) 

0 (Service Set Identifier) 
3 octet (s) 



1 (Supported Rates) 
» 4 octet (s) 



Broadcast 



.Supported Rates information field -02 



.000 0010 

.Supported Rates information field 



.000 0100 

. . .Supported Rates information field 

0 

.000 1011 

. . .Supported Rates information field 

0 

.001 0110 



Hot Basic Service Set Basic Rate 
1.0 Megabits per second 
04 

Hot Basic Service Set Basic Bate 
2.0 Megabits per second 
OB 

Hot Basic Service Set Basic Rate 
5.5 Megabits per second 
16 

Hot Basic Service Set Basic Rate 
11.0 Megabits per 



00000000: 
00000010: 
00000020: 04 0b 16 



00 03 55 4e 40 01 04 02 E 



FDtersd 3 i 



Figure 56 
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S Sniffer Wireless - LocalJZ, 802.11 Wireless LAN (Line speed at 11 Mbps) DS Channel 6:4i!ighal;LeVeJf B'^MMSfPiGlI 




602.11: 1.0 Mbps. 5icn&l=100>: . Probe i-esponse 




BSlDICl" fimestairi 



DLC: 
DLC: 
DIjC: 
DLC: 
DIG: 
DIC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
-QDLC: 
-QDIC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DIC: 
DLC: 
DLC: 
IDLC 



Beacon Interval 



100 



00.. 



Capability information field #1 « 02 

. .0 » Extended Service Set is of f 
.1. - Independent Basic Service Set is on 

■ Ho point coordinator at Access Point 
■ Ho privacy 

° Short Preamble option is not allowed 
° Packet Binary Convolutional Coding Hodulation 

0 « Channel agility is not in use 

Capability information field #2 =00 

0000 0000 ° Reserved 



.0 
0. 



Element ID 
. . .Length 

, . .Service Set Identity 



- 0 (Service Set Identifier) 

- 12 octet(s) 

- "snifferadhoc" 



Element ID =1 (Supported fetes) 

. . .Length * 4 octet(s) 

...Supported Rates information field ■ 82 

1 * Basic Service Set Basic Rate 

.000 0010 ° 1.0 Megabits per second 

. . .Supported Bates information field "04 

0 ■ Hot Basic Service Set Basic Rate 

.000 0100 = 2.0 Megabits per second 

...Supported Rates information field a 0B 

0 . . . .... - Hot Basic Service Set Basic Rate 

.000 1011 ■ 5.5 Megabits per second 

. . .Supported Rates information field ■ 16 

0 = Hot Basic Service Set Basic Rate 

.001 0110 -11.0 Megabits per second 



Element ID 
. . .Length 

. . .dotllCuxTentChannelHumbsr 



■ 3 (Direct Sequence Parameter set) 
» 1 octet (s) 
« 6 



Element ID =6 (Independent Basic Service Set Parameter set) 

. . .Length * 2 octet (s) 

...Announcement Traffic Indication Message vindov » 0 (in Time Unit) 



QOOOQOOO: 50 00 02 01 00 40 96 30 c2 8c 00 40 96 34 8 a d7 P glOAl .@|4|X 

00000010: 4a 03 30 00 2f 01 cO la KHM^^^raSMSMl J .0 ./.A.CZZZZI 
00000020: 64 00 02 00 00 Oc 73 6e 69 66 66 65 72 61 64 68 d snifferadh 
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Sniffer Wireless - Loca!_2 P 802.11 Wireless LAN (Line speed at 11 Mbps) OS Channel fr - Signal; Uv&jjtk^^^^^ 




DIC 
DLC 
DIC 
DLC 
DIC 
DIC 
DIC 
DIC 
DIC 
DIC 
_ DIC 
-Q DLC 
DIC 
DLC 
DLC 
DIC 
DLC 
DLC 
DLC 
DLC 
DIC 
DIC 
DIC 
DLC 
DLC 
DLC 
DLC 
DIC 
DLC 
DIC 
DLC 
DLC 
DLC 
DLC 
DLC 
DLC 
DLC 
DLC 
DLC 



Timestamp - 334336901 (in Microseconds) 

Beacon Interval ° 100 

Capability information field #1-02 

. . .0 - Extended Service Set is off 

. . 1 . " Independent Basic Service Set is on 



.. 00. 
.0 ... 
0. ... 



0... 



Capability information field #2 = 00 
0000 0000 



Element ID 
. . .Length 

. . .Service Set Identity 

Element ID 
. . .length 

. . .Supported Rates infornatian field 

1 

.000 0010 

.. .Supported Bates information field 

0 

.000 0100 

. . .Supported Rates information field 

0 

.000 1011 

. . .Supported Rates information field 

0 

.001 0110 



Ho point coordinator at Access Point 
« Ho privacy 

= Short Preamble option is not al loved 
- Packet Binary Convolutional Coding Modulation 
Channel agility is not in use 



- 0 (Service Set Identifier) 
° 12 octet(s) 
■ "snifferadhoc" 

« 1 (Supported Sates) 
= 4 octet(s) 
82 

Basic Service- Set Basic Rate 
1.0 Megabits per second 
04 

Not Basic Service Set Basic Rate 
2.0 Megabits per second 
0B 

Hot Basic Service Set Basic Rate 
5.5 Megabits per second 
16 

Hot Basic Service Set Basic Rate 
11.0 Megabits per second 



Element ID 
. .length 



* 3 (Direct Sequence Parameter set) 
- 1 octet (s) . 



. . .dotllCurrentChannelHumher * 6 

Element ID * 6 (Independent Basic Service Set Parameter set) 

. . .length * 2 octet (s) 

. . .Announcement Traffic Indication Message Window ■ 0 (in Time Unit) 



00000000: 

lOOOOOOlO: {4a£QlS3tfcfl(ft^ Dtf&dZiB 85 93 ed 13 00 00 00 00 titoBtifflffiM i !i . 

00000020: 64 00 02 00 00 0c 73 6s 69 66 66 65 72 61 64 68 d sniff eradh 

100000030: 6f 63 01 04 82 04 0b 16 03 01 06 06 02 00 00 oc.l. 



Figure 58 
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£^ Sniffer Wireless - Local, 802.1 1 Wireless LAN (Line speed at 11 Mbps) DS Channel 6 - Signal Level 7U ^ - la'SS&'t^j^^^^ 




DLC Header 



DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC; 
DLC: 
DLC: 
DLC: 
DLC: 
-QDLC: 
DLC: 
_ DLC: 
hgDXC': 
H3 DLC: 
UQDLC: 
-QDLC: 



Frame 1352 arrived at 
Signal level 
Channel 
Data rate 

Frame Control Field #1 

00 

00.. 

1010 

Frame Control Field #2 
... .0 
. ..0. 
. .0.. 



Duration 

Destination Address 
Source Address 
Basic Service Set ID 
Sequence Control 
. . .Sequence Number 
. . .Fragment Knit her 
Reason code 



08:39:38.9406; frame size is 26 (001A hex) bytes. 
» 100K 
» 1 

"4(2.0 Megabits per second) 

AO 

0x0 Protocol Version 
0x0 Hanagenent Frame 
OxA Disassociation (Subtype) 
00 

Hot to Distribution System 
Hot from Distribution System 
Last fragment 
Hot retry 
Active Hade 
Ho mare data 

Wired Equivalent Privacy is off 
Hot ordered 

- 258 (in microseconds) 
° Station Airont2AlA39 
= Station Airont3080F2 
■ Airont3080F2 

- 0xE940 

- 0xE94 (3732) 

- 0x0 (0) 

= 8 (Disassociated because sending station is leaving 
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Frame 259 arrived at 
Signal level 
Channel 
Data rate 



Frame Control Field #1 

00 

00.. 

1011 .... 
Frame Control Field #2 

0 

0. 

0.. 

.... 0... 

...0 .... 

..0 

.0 

0 

Duration » 
Destination Address » 
Source Address » 
Basic Service Set ID 
Sequence Control 
. . .Sequence Number = 
. . .Fragment Humber 
Authentication algorithm number 
Authentication transaction sequence number - 2 
Status code » 0 (Successful) 

Element ID = 16 (Challenge Test) 

...length - 128 octet(s) 

T128 bytg(s) of challen ge , textl 



0x0 Protocol Version 
0x0 Management Frame 
OxB Authentication (Subtype) 
00 

Hot to Distribution System 
Hot from Distribution System 
Last fragment 
Hot retry 
Active Mods 
Ho more data 

Wired Equivalent Privacy is off 
Hot ordered 

■ 314 (in microseconds) 
» Station IntrslQ1014F 
» Station Symbol8E021E 
=» Symbol8E021E 
- 0xE230 

■ 0xE23 (3619) 
» 0x0 (0) 

1 (Shared Key) 



a 



00000000: 
00000010: 
00000020: 
00000030: 00 
00000040: 06 
00000050: 4a 
00000060: 26 
o fin a Qji aiiA^UL 



*>.^«t,«w-s^~. u*H*xsa 01 00 02 00 00 00 10 »u ma? 

39 46 55 69 B7 ad de 12 le* 2c 3d 47 54 64 73 u9FUil-t>. 

bO cd 12 05 12 03 15 Od 08 13 Od 0b 11 08 14 1*1 

27 11 37 67 a4 e8 04 22 02 2b If Od 3c 66 51 . ' .7g«e. " .+. . <fQ 

6c b6 dl 36 77 al ff 09 33 06 3d 77 a8 ef 14 Jlflft6vly.3.-v"i. 

6f cb bf ad 9c 86 el 5e 3d 05 4c 14 55 27 7e &ofi£-lla/ % «.L.[T'* 
^J^Jj^O^Mx J-4_na_JC^Jl^A-ji3L. CU AQ oo ftp. ~ rtnji^kfipflL . 
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Sniffer Wireless - Local, 002.11 Wireless LAN (Line speed 




DLC 
DLC: 
_ DLC: 
-QDLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 
DLC: 



Frame 59 arrived at 
Signal level 
Channel 
Data rate 



08:22:47.4498; frame size is 26 (001A hex) bytes. 
- 100* 
» 1 

*4(2.0 Megabits per second) 



Frame Control Field #1 

00 

.... 00. . 
1100 



| DLC: Frame Control Field #2 
|D3jC: 0 



.0. 
0. . 



0. 



I DLC: 
(DLC: 
|DLC: 
>DLC: 
\ DLC: 
I DLC: 

*DLC: 0... ;. 

| DLC: Duration 

\ DLC: Destination Address 

\ DLC: Source Address 

| DLC: Basic Service Set ID 

i DLC : Sequence Control 

\ DLC: . . .Sequence Number 

j DLC: . . .Fragment Kumber 

} DLC: Reason code 



0. » 



CO 

0x0 Protocol Version 

0x0 Management Frame 

OxC Deauthentication (Subtype) 

00 

Hot to Distribution System 
Hot from Distribution System 
Last fragment 
Hot retry 
Active Mode 
Ho more data 

Fired Equivalent Privacy is off 
Hot ordered 

= 25B (in microseconds) 

« Station Intrsl01014F 

- Station Airont3080F2 
» Airont3080F2 

- 0x0090 

= 0x009 (9) 
» 0x0 (0) 

D 2 (Previous authentication no longer valid) 



^Filtered 2/% 



w 



Figure 61 
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® Sniffer Wireless - Local, 802.11 Wireless LAN (Line speed at U Mbps) DS Channel - Signal Lev«|.'7£*/« v - l^l^gfiH^S 

• : i m i i i »!■ urn iii 1 1 ■ i iiiiiii rriii iid imrtrnri'i«iiMi'^iir»nifi«nlnifiiiii f» ^<l 




DLC: 








DIC: 


Frame 1167 arrived at 


17:06:45.7516; frame size is 16 (0010 


DLC: 


Signal level 




* 67 % 


DIC: 


Channel 




« 1 


DIC: 


Data rate 




= 2(1.0 Megabits per second) 


DLC: 








DIC: 


Frame Control Field #1 


3 


A4 


DIC: 


00 




0x0 Protocol Version 


DIC: 


.... 01.. 


S 


0x1 Control Frame 


DIC: 


1010 .... 




OxA Bover Save (PS) -Poll (Subtype) 


DIC: 


Frame Control Field 92 




10 


DLC: 


0 


a 


Hot to Distribution System 


DIC: 


0. 


e 


Hot from Distribution System 


DIC: 


0. . 


a 


last fragment 


DIC: 


.... 0... 




Not retry 


DIC: 


...1 .... 


a 


Pover Save Mode 


DLC: 


..0 


s 


No more data 


DIC: 


.0 


■ 


Fired Equivalent Privacy is off 


DIC: 


0 




Not ordered 


DIC: 


Association ID 




o 24 


DIC: 


Basic Service Set ID 




» Station Synbol9324DB 


DIC: 


Transmitter Address 




« Station Airont2B55F6 
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g^Sniffer Wireless - Lacal, CQ2.1 1 Wireless LAN (Line speed at 11 Mbps) OS Channel 6 -SignahLeveJ 75^> CCisrn^ioij 



Airont315EB9 i Airgnt3A21ED 1802.11: 1.0 Itbps. Signal- 57~. Request To Send CR1W~ 




we 



17:06:44.1170; frame size is 16 (0010 hex) bytes. 

- 57 Z 

- 1 

-2(1.0 Megabits per second) 

Frame Control Field #1 - B4 

00 » 0x0 Protocol Version 

.... 01 . . - 0x1 Control Frame 

1011 .... - OxB Request To Send (RTS) (Subtype) 
Frame Control Field #2 * 00 

. . . 0 ■ Hot to Distribution System 
, . 0 . "Hat from Distribution System 
- last fragment 
■ Hot retry 
» Active Hods 
» Ho more data 

» Wired Equivalent Privacy is off 
• Hot ordered 

» 1005 (in microseconds) 
■ Station Airont3a21ED 
» Station Airont315EB9 
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^Snifter Wireless - Local, 002.11 Wireless IAN (Line speed at It Mbps)D5 Channel 5 -SignalXeVd 68 jfa * J^^^i^|SjSl^l i 





I [207.46.238.571ITCP: D 3 80 S-1259 



ACK»3597913453 UIH-7494 



Airont2855F6 1802.11: 1 0 Mbps, Signal* 10Q&, Acknowledqr.ent (ACK)IIO I 0:00:00. 



0 :00: 001 



I WINS: 



B4© 




C ID"34195 QP a REFR£5H KAHE>< AC>0< 9996 >1793<8 0Bl 129 j 

. — ^.. 



|DIC: 
}DIC: 
I DLC: 
>DLC: 
hDLC: 
\DUC: 
I DLC: 
i DLC: 
|DLC: 
I DLC: 
i DLC: 
| DLC: 
i DLC: 
IDLC: 
iDIC; 
\ DLC: 
| DLC: 
\ DLC: 
\ DLC: 
JDIC: 
i DLC: 
\ DLC: 




Frame 4 arrived at 
Signal level 
Channel 
Data rate 



17:06:44.0017: frane size is 10 (000A hex) bytes. 
■ 100* 
- 1 

» 2 ( 1.0 Megabits per second) 



Frane Control Field #1 

00 

.... 01.. 
1101 .... 

Frane Control Field t2 



. .0 
.0. 
0.. 



.0 

0. 



Duration 
Receiver Address 



D4 

0x0 Protocol Version 
0x1 Control Frame 

OxD Acknowledgment (ACK) (Subtype) 
00 

Hot to Distribution System 
Hot from Distribution System 
Last fragment 
Hot retry 
Active Mode 
Ho more data 

Ifired Equivalent Privacy is off 

Hot ordered 

* 0 (in microseconds) 
= Station Airont2855F6 



Implied Transmitter Address =» Station Symbol9324DB 



00000000: 



Figure 64 
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gej^jl Decode L ^SSStfffi^/tlto^ffiaM^/g PratBc^ Jgfe^A' jSt^lKaj^3 ^f 



Rgure65 
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To¥ire006006 (Broadcast 1602.11: 2.0 Mbns, Sianal= 94>I . Contention Free (C£ 



I D1C 
I DIC 
I DIC 
\ DIG 
i DIC 

i Die 

> DIC 
I DIC 
| DIC 
i DIC 
i DIC 
1 DIC 
i DIC 
I DIC 
I DIC 
I DIC 
\ DIC 
i DIC 
JDIC 

i Die 
[Die 
I Die 



Frame 2 arrived at 
Signal level 
Channel 
Data rate 



12:47:32.0353; frame size is 16 (0010 hex) bytes. 
- 94 % 
= 6 

"4(2.0 Megabits per second) 



Frame Control Field #1 

00 

01. . 

1110 

Frame Control Field #2 



. .0 
.0. 
0. . 



..0 ... 
.0. ... 

0 

0 

Duration 
R e ce iver Address 
Basic Service Set ID 



- E4 

a 0x0 Protocol Version 

• 0x1 Control Frame 

» OxE Contention Free (CF)-End (Subtype) 
» 00 

- Not to Distribution System 

- Hot from Distribution System 
° last fragment 

* Hot retry 

« Active Hods 
s No more data 

- Uired Equivalent Privacy is off 
■ Not ordered 

* 0 (in to i c T P SBc on ds ) 

* BROADCAST FFFFFFFFFFFF. Broadcast 
» Station NoT?ire006006 



9 



0000000: 



Figure 66 
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^Sniffer Wireless - Local, 802.11 Wireless LAN (Line speed at 1 1 Mbps) DS Channel G ; < Sfgnal CeVeF 68;?»V~ LL^f^ayfn^fe 








Frame 213 arrived at 
Signal level 
Channel 
Data rate 

Frame Originally Encrypted vitb TCP key 



Frame Control Field #1 

00 

10.. 

0000 

Frame Control Field #2 
. . . .0 
. . .1 
. .0. 



Duration 

Destination address 
Basic Service Set ID 
Source address 
Sequence Control 
. . .Sequence Number 
. . .Fragment Number 



■ 0x0 Protocol Version 
= 0x2 Data Frame 
° 0x0 Data (Subtype) 
- 42 

■ Not to Distribution System 

■ From Distribution System 

* Last fragment 
° Not retry 

» Active Mode 

■ No more date 

■ Vired Equivalent Privacy is on 

* Not ordered 

* 0 (in microseconds) 

* BROADCAST FFFFFFFFFFFF. 
« Station Airont340C54 

» Station Airont30C28C 
» 0x93A0 

* 0x93A (2362) 
- 0x0 (0) 



Broadcast 



¥EP (Aired Equivalent Privacy) Header 
. . .Initialization Vector #(l-3)» EE3E20 
. . .Initialization Vector #4 - 6C 

01 » 1 (Key ID 2) 

. .10 1100 - Pad 
, . . [328 byte(s) of encrypted MSDU] 
. . .Encrypted Integrity Check Value » C42E6839 

00000000: " 
00000010: _ 

00000020: 9e 3b 95 54 56 4b cf Id d2 b7 17 24 47 b£ 3f 60 I; IT 
00000030: £6 2b 20 18 b9 21 d2 be 08 98 83 07 di c3 9e el 6+ 



■7. te.J i ldl^fl^f£$j&* 



i _ 

,._.0- .$Gi? 
I OK. II.BSla 



wmmB 
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^Sniffer Wireless - Local, 802.11 Wireless LAN (Line speed at It Mbps) OS Channel G t Signal Level* 73 °/o - rW^nn^De^iSSMi 




ijaSgggl [6] DCAFAREL_1I0TEB0 [132.163.1.255] 802.11; ll.O^libps, Signal-100*, Data, IJEP 

fnlSHn SNAP: Ethei>net 4i Tvpe=OS00 (IP) fcjf 

MS IP : D«[192. 168. 1.255] S= [ 192 . 168 . 1 . 2 ] LOf-gg? 

fll^Hi UD fi D=137 3 = 137 LEtr»S8 ^ ^ ^ |3| 



iDIC: 
J DIC: 
IDIC: 
|D1C: 
I DIG: 
|D1C: 
iDIC: 
IDIC: 
iDIC: 
iDIC: 
IDIC: 
iDIC: 
iDIC: 
iDIC: 
IDIC: 
iDIC: 
iDIC: 
iDIC: 
iDIC: 
IDIC: 
iDIC: 
| DIC: 
IDIC: 



Fran© Originally Encrypted vith 9EP key 1 



Frame Control Field #1 

00 

10.. 

0000 

Frane Control Field $2 



. . .0 
..0. 

.1.. 



Duration 

Destination Address 
Basic Service Sot ID 
Source address 
Sequence Control 
. . . Sequence Number 
. . . Fragment Number 



08 

0x0 Protocol Version 
0x2 Data Frame 
0x0 Data (Subtype) 
42 

Not to Distribution System 
From Distribution System 
last fragment 
Not retry 
Active Kode 
No more data 

Virod Equivalent Privacy is on 
Not ordered 

° 0 (in microseconds) 

- BROADCAST FFFFFFFFFFFF, 
• Station InksysOCOA09 

■ Station Dell F5640E 

- 0xFA30 

° 0xFA3 (4003) 

- OxO (0) 



.Initialization Vector #(1-3)- FF0O0O 

.Initialization Vector #4 » 00 

00 o 0 (Key ID 1) 

. .00 0000 - Pad 



DIC: 
__ DIC: 
~Q DLC: 
DIC: 
DIC: 

P-TTIXC: C D-AA S-AA UI 

SNAP: Ethernet Type°0800 (IP) 

IP: D=[192. 168. 1.255] S»[192 . 168 . 1 . 2] LEN-58 ID=240 
ffl-TJUDP: D«137 S*13? IEN-S8 

i-^WINS: C ID=33036 OP-QUERY NAME«NAICOH<202020202020202020><00> 
DIC: ...Decrypted Integrity Check Value » 36913444 



'00000000: 08 42 00 00 it it it it ff £f 00 04 5a 0c 0© 0? 
00000010: 00 c0 4f £5 64 Oe 30 fa i^SBgffiEE&ni aa aa 03 00 

™ an 11 




■W I iLL.. 



Figure 68 



WO 03/025597 PCT/US02/29303 



69/73 



ggBiia^^ . r . 



Defau* 



DCAFAREL_NOTEEO [192.163.1.255] 302.11: 11.0 Mbps, Signal=100fc, Data. WEP ?«« 

LLC: C D=AA S=AA UI 
SNAP: Ethernet Type-0800 (IP) 
IP: D=[192. 168. 1.255] S-[192 .163 . 1 . 2] LEHt& 
UDP: D=137 S=137 IEi, r =59 m 



' ^ths ■ jCJ^^^ttt ^ "QEs'"' it FSX LHAKEsltii T £GfJU- 7 o? n 



Megabits per second) 



QdLC: 

QDLC: Frame 7 arrived at 09:27:19.6954; frame size is 118 (0076 hex) bytes. 
DLC: Signal level - lOOfc 

DLC: Channel ■ 6 

DLC: Data rate - 22 (11.0 

DLC: Short Preamble 

DLC: Frame Originally Encrypted with TOP key 1 
DLC: 

- 08 

« 0x0 Protocol Version 
» 0x2 Data Frame 

* 0x0 Data (Subtype) 

- 42 

« Hot to Distribution System 
■* From Distribution System 
« Last fragment 
■Hot retry 
■» Active Mode 

- Ho more data 

* Hired Equivalent Privacy is on 
« Hot ordered 

«* 0 (in microseconds) 



i DLC: 
i DLC: 
I DIC: 
>DIC: 
\ DLC: 
\ DIC: 
i DIC: 
i DIC: 
( DIC : 
i DIC: 
i DIC: 
I DLC: 
i DLC: 
i DIC: 
1 DIC: 
i DLC: 
i DIC: 
\ DLC: 
i DIC: 
i DIC: 
I DLC: 
i DLC: 
t DLC: 
i DIC: 
i DLC: 
\ DLC: 



Frame Control Field #1 

00 

10. . 

0000 

Frame Control Field #2 
. . .0 
. .1 



Duration 
Destination Address 
Basic Service Set ID 
Source address 
Sequence Control 
. . .Sequence Number 
. . .Fragment Number 



BROADCAST FFFFFFFFFFFF. 
Station Lnksys0C0A09 
Station Dell F5640E 
0xFA30 
0xFA3 (4003) 
0x0 (0) 



Broadcast 



VEP (Wired Equivalent Privacy) Header 
. ..Initialization Vector *(l-3)= FF00O0 
. . . Initialization Vector #4 =00 

00 « 0 (Key ID 1) 

. .00 0000 » Pad 




Figure 69 
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^Sniffer Wireless - Locals 802.1 1 Wireless LAN (Une speed at 1 1 Mbps) OS Channel 6 - Signal'Level- 70 



E'LC: DLC 



Frame 16 arrived at 
Signal level 
Channel 
Data rate 



13:15:40.5567; frame size is 1067 (042B hex) bytes. 

- 94 Z 

- 11 

- 22 (11.0 Megabits per second) 



Frame Control Field #1 

00 

.... 10.. 
0000 .... 

Frame Control Field #2 



1 

0. 

0.. 

...0 ... 
..0. ... 

.0 

0 

Duration 
Receiver Address 
Transmitter Address 
Destination Address 
Sequence Control 
. . .Sequence Number 
. . .Fragment Number 
Source Address 

IXC Header 



» Q8 

« 0x0 Protocol Version 
- 0x2 Data Frame 
" 0x0 Data (Subtype) 
= 03 

a To Distribution System 
° From Distribution System 

* last fragment 

* Not retry 

» Active Mode 
= No more data 

9 tfired Equivalent Privacy is off 
° Not ordered 

- 258 (in microseconds) 

- Station Airont2595D4 
» Station Airont27D5AA 
« Station Packet 30286 6 
« 0x8690 

- 0x869 (2153) 

- 0x0 (0) 

- Station Compaq46144A 



DSAP Address « AA, DSAP IG Bit - 00 (Individual Address) 



00000000: 
00000010 
00000020: 03 
00000030: 18 
00000040: b3 
00000050: 6f 
00000060: 
00000070: 
00000080: 



68 
61 
71 



00 00 00 08 

ef 84 bl 75 

26 61 62 63 

70 71 72 73 

69 6a 6b 6c 

62 63 64 65 

72 73 74 75 
6^6c„MJiflL 



00 46 00 04 
ac 84 bl 75 
64 65 66 67 
74 75 76 77 
6d 6e 6£ 70 
66 67 68 69 
76 77 61 62 
6f 70 71 72 



05 89 
81 08 
68 69 
61 62 
71 72 
6a 6b 
63 64 
2.3L24. 



79 00 
00 30 
6a 6b 
63 64 
73 74 
6c 6d 
65 66 



aa aa 

20 01 
03 00 
6d 6e 
66 67 
76 77 
6f 70 
68 69 



..E...|y.. 
.i|±u-|±u|. .09. . 
* Scabcdef ghi j klmn 
opqrstuwabcdef g 
hi j k 1 mnopqrs t uw 
abcdefghijklmnop 
qrs t uwabcdef ghi 



j Deccdajf 



Rgure70 



WO 03/025597 



PCT/US02/29303 



71/73 



^Sniffer Wireless - Local, 8Q2.lt Wireless LAN (Line speed at 1 1 Mbps) 05 Channel 6 - Signal LeveL'fieSbrOi^^i^SSHffi 





Uiront340C54 I Broadcast 1 802 . 11 : 1.0 HbDS. Siqnal=100X. Eeacon 



[6] IAiront340C54 



Broadcast 



802.11: 1.0 Mbps, Signal»100*, Beacon 

I ft fl 9 11* 1 fl Win — 



. . .length » 4 octet (s) 

. . .Supported Rates information field ■ 82 

1 ■ Basic Service Set Basic Rate 

.000 0010 » 1.0 Megabits per second 

. . .Supported Rates information field ° 84 

1 * Basic Service Set Basic Rate 

.000 0100 = 2.0 Megabits per second 

...Supported Rates inf ox-nation field = 8B 

1 . . . B Basic Service Set Basic Rate 

.000 1011 » 5.5 Megabits per second 

. . .Supported Rates information field ■ 96 

1 " Basic Service Set Basic Rate 

.001 0110 a 11.0 Megabits per second 




Element ID 
. . .length 



3 3 (Direct Sequence Parameter set) 
■ 1 octet (s) 



. . .dotllCurrentChannelHumber - 6 

Element ID =5 (Traffic Indication Map) 

. . .Length = 4 octet (s) 

. . .Delivery Traffic Indication Message Count ■ 1 
. . .Delivery Traffic Indication Message Period * 2 
. . .Bitmap control field « 00 

0 ■ Traffic Indicator bit 

0000 000. « 0 Bitmap offset 
. . .Partial Virtual Bitmap * 00 

Element ID ■ 133 (Unknown Information Field) 

...length ■ 30 octet(s) 

... [30 byte(s) of Unknown Information Field] 




00000010: 
00000020: 
00000030: 
00000040: 
I 00000050: 
00000060: 



al f 1 d8 db 37 00 00 00 MSMmM\M!7 . , 

64 00 31 00 00 19 73 6e 69 66 66 65 72 20 74 65 d.l. . .sniffer te 

63 68 6e 6f 6c 6f 67 69 65 73 20 6c 65 61 70 01 chnologies leap. 

04 82 84 8b 96 03 01 06 05 04 01 02 00 00 85 le .1111 |. 

00 00 4c Od 07 00 ff 03 01 00 77 61 79 2d 61 70 . .1. . .y. . .vay-ap 

2d 6c 65 61 70 2d 36 00 00 00 00 00 00 0c -leap-6 
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.000 0010 9 1.0 Megabits per second 
.Supported Rates information field a 84 

1 ° Basic Service Set Basic Sate 

.000 0100 - 2.0 Megabits per second 
.Supported Rates information field ° OB 

0 • Hot Basic Service Set Basic Rate 

.000 1011 " 5.S Megabits per second 
.Supported Rates information field ■ 16 

0 ■ Hot Basic Service Set Basic Rate 

.001 0110 » U.O Megabits per second 



Element ID 
. . .length 

. . .dotllCurrentChannelHuaber 

Element ID 

. . . length 

. . .CFP Count 

. . .CFP Period 

. . .CFP Maximum Duration 

. . .CFP Duration Remaining 



3 (Direct Sequence Parameter set) 
1 octet(s) 

6 

4 (Contention Free Parameter set) 
6 octet (s) 

0 
1 

140 (in Time Unit) 

140 (dotUCurrentPattem) 



5 (Traffic Indication Hap) 
4 octet(s) 



Element ID 
. . .length 

. . .Delivery Traffic Indication Message Count • 0 

. . .Delivery Traffic Indication Message Period ■ 2 

...Bitmap control field • 00 

0 * Traffic Indicator bit 

0000 000. * 0 Bitmap offset 

. . .Partial Virtual Bitmap =00 





TOooooo 

00000010; B0Mfe^ft0| $fl&tiffftffi^ 9a 21 3f Of 00 00 00 00 _ 

QOOOQ020: 64 00 05 00 00 04 74 65 73 74 01 04 82 84 0b 16 d test.. II 

00000030: 03 01 06 04 06 00 01 8c 00 8c 00 05 04 00 02 00 !.|. . .. 

00000040: 00 
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^Sniffer Wireless - Local, 802.U Wireless LAN (Line speed at 1 1 Mbps) DS Channel 5 -'Sinnal Level; 70i«'o - [iitteV<iil'slftfe:^iiw|& 



Frame Control Field #1 

00 

.... 00.. 

1011 

Frame Control Field *2 

0 

0 

... .0. 
.. 0.. 
.0 ... 
.0. ... 



Duration 

Destination Address 
Source Address 
Basic Service Set ID 
Sequence Control 
. . .Sequence Number 
. . .Fragment Number 

Authentication algorithm number n 1 (Shared Key) 
Authentication transaction sequence number ■ 2 
Status cods - 0 (Successful) 

Element ID =16 (Challenge Test) 

. . . length « 128 octet <s) 



DIC: [123 byte(s) of challenge text] 



0k0 Protocol Version 
0x0 Management Frame 
OkB Authentication (Subtype) 
00 

Not to Distribution System 
Not from Distribution System 
last fragment 
Not retry 
Active Mode 
No more data 

Vired Equivalent Privacy is off 
Not ordered 

" 314 (in microseconds) 

- Station Intrsl01014F 

- Station Symbol8E021E 
«* Symbol 8E02 IE 

- 0sE230 
° 0xE23 (3S19) 
* 0x0 (0) 



I 
I 

I 



1 



I DIC: 



00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 
00000060: 
00000070: 
00000080: 
00000090. • 



bO 00 3a 01 00 30 b4 01 01 4f 00 aO f8 8e 02 le 
00 aO |8 Be 02 le 30 eg 01 00 02 00 00 00 10 80 
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